![]() |
|
Do you know where your variables are? | |
PerlMonks |
comment on |
( #3333=superdoc: print w/replies, xml ) | Need Help?? |
Thanks for the through reply. I have to admit that I feel more confused when I started though. Looking at the various implementations of roles and traits it seemed the other way around in complexity based on their APIs. I'm interested in these sort of OOP concepts, but for the moment I'm just going to focus on how this sort of concept would apply to MT as it exists today and in the foreseeable future. > This "-able" thing is more aligned to how people use Java interfaces, which is only one way in which Roles/Traits can be used.So this -able concept could (should?) be a role or trait even if its not using the full spectrum of possibilities right now. > None one of the above, all those modules should be considered toy implementations and are all woefully incomplete. The only complete and thoroughly tested Role implementation on the CPAN is Moose::Role.I don't see being incomplete as an entirely bad thing. MT now makes use of YAML at ever increasing levels, but only uses YAML::Tiny for the processing. Given the complexity of the app and its installation and its prerequisites I see anything that can simplify and slim down the system as a great thing. So while these implementations are "toys" how is their upwards compatibility with the full roles vision? If one of these classes provides enough of the functionality MT needs now, like YAML::TIny is to YAML, I don't see what it would hurt to use it. Based on how I laid things out would do you think Roles in, even in the limited submit that these modules present, is better then the current multiple inheritance scheme MT is using thus far? In reply to Re^2: Sanity Check: Roles vs. Traits
by tima
|
|