Front page | perl.perl5.porters |
Postings from December 2008
2008/12/16 Steffen Mueller <wyp3rlx02@sneakemail.com>: > But we're pretty off-topic now with regards to your class patch. I thought > about this whole issue some more and feel it all comes down to requiring a > plan. A roadmap. Where should the perl(5!) core be in five years given > enough developer time? What happens to those plans if you adjust them for > the very finite amount of labour available? Or let me rephrase: > > Pumpkings, what do you *want* and expect? Surely not a single core-level > patch that implements the whole of Moose and Perl6 on top running at the > speed of hand-crafted assembly? If there is a plan, small steps in the right > direction are okay. If there is no plan, only the one perfect shot is likely > to satisfy everyone. Yes. We need a plan. First, a general word. My preference in improving perl during the 5.10 development (and still now) is to make it more useable for large projects. Remove or temper things that have effects at distance. Make magic behaviours more robust and predictable. Improve compile-time checking. The 2nd important point is to make perl extensible. This is hard; but to enable better metaprogramming we need to make the optree and symbol table interfaces more robust. The 3rd important point is: don't break the CPAN. I don't want to add a class keyword just for the sake of syntax. (BTW, chromatic, if we add a class keyword it probably needs syntax sugar for the mro pragma, too.) I'll add a class keyword only if it proves itself useful to developers. One of Ricardo's ideas for 5.12 was to make a distinction between methods and subs, and have a way to know whether a sub has been called as a method or a sub. With classes, we could for example forbid calling methods as subs (if not called with the & syntax). We could also optionally check at compile-time if a method exists (that would be a class attribute -- obviously we don't want to forbid AUTOLOAD in classes). That wouldn't work in all cases, but sufficiently to be useful. I'm making the assumption here that @ISA would be immutable for classes declared with the class keyword. See, there are many ideas that are applicable and room for discussion. My advice would be to create a branch in git for experimentation and maturing of those ideas. Branching is cheap, and so the code would be accessible publicly.Thread Previous | Thread Next