First off, nice additions to the RFC.
> Listed below are constructor alternatives. If a sub is chosen (as in sub
> PREPARE {}) it will suffer from the disadvantage of potentially causing
> problems with current Perl modules.
I don't really think this is a valid concern. We can have p52p6 warn
them, and all other Perl stuff (tie's STORE/FETCH, Perl's DESTROY, etc)
are already done by ALLCAPS subs, just like global vars are $ALLCAPS.
Besides, what would be the alternative, BEGIN{} - like blocks? I think
these should just be subs, that way the user can call them at will as
well. It also makes the implementation easier, just call the appropriate
sub if it exists.
> If an appropriate constructor is not provided a fatal exception should be
> raised when the syntax is used.
Naw, I don't think we should go this route. If it's not a valid imported
package, then the statement should die. But not defining a constructor
should only yield a warning with -w:
No implicit constructor defined by package Dog at line 47.
At the very most.
> This definition would probably be best provided through a pragma:
>
> use constructor qw(new);
I also don't think we should do this. There's nothing more special about
CREATE/PREPARE/NEW than DESTROY, STORE, or FETCH. We should provide what
we think is a good name (and perhaps some alternatives), and let Larry
decide.
I'm very much against allowing people to tweak absolutely everything.
There are minimal gains for marked losses in consistent, readable,
maintainable code. See this link for a rant on how this can go really
bad really quickly:
http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00131.html
-Nate
