develooper Front page | perl.perl5.porters | Postings from December 2008

Re: [PATCH] Class as a Feature (take four)

Thread Previous | Thread Next
From:
Rafael Garcia-Suarez
Date:
December 16, 2008 00:56
Subject:
Re: [PATCH] Class as a Feature (take four)
Message ID:
b77c1dce0812160056w4f62d44cyb74cf44291e64dcb@mail.gmail.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About