Front page | perl.perl5.porters |
Postings from March 2007
On Sunday 11 March 2007 12:36, demerphq wrote: > > 3) Hiding method calls underneath function calls is a well-established > > practice in Perl 5 -- you can see it in such clean and easily maintained > > code as the magic system. Adding a new feature to the core by the way of > > a hack seems to go against good design principles. > I think its too late for this one. If Perl 5 had a different design it > might be worth taking this perspective, but as they say, that horse > bolted a long time ago. Why restrict something that goes a long way to > cleaning up the mess simply because there is a mess? Calling it UNIVERSAL::DOES() -- when DOES() is a method in UNIVERSAL adds to the mess. > > I believe the right approach to making ->DOES() work on built-in types is > > through autobox. > This is a huge change with ramifications far beyond maintaining > UNIVERSAL::DOES() as a special method. Theres no way it could happen > until long after DOES locks itself into a set of behaviour by being > published as part of Perl 5.10. What we dont change before then wont > get changes. What locked set of behavior? UNIVERSAL::DOES() right now adds a single method with a documented behavior to all classes. There's no reason that can't apply to built-ins in the future. > > An alternate approach is to add a does() built-in, like ref() but > > actually useful. > Thats basically the point of this patch. Then it should become a new operator like ref() or err(). UNIVERSAL::DOES() is the wrong name. -- cThread Previous | Thread Next