John Siracusa wrote:
>
> I'm pretty sure one of the big points about the system described is that it
> ensures both that there's always a predictable and automatic chain of events
> for SETUP/DESTROY (without requiring the programmer to create and document
> his own bug-free implementation) and it ensures that each routine is called
> only once, regardless of multiple inheritance paths.
The "multiple inheritance paths" one is good. I like that part a lot.
But the rest makes me really nervous if there's no way to override or
change it.
> Actually, I'd be happy with an RFC for an entirely new method of object
> creation and identification that has nothing to do with bless
I think this RFC could work for this, but as I noted in a private email
to Damian I'd rather see a whole new keyword made, maybe "setup"?
sub new { setup {}, @_ }
sub SETUP { ... }
One thing nobody's brought up is this: What if you decide you want the
standard Perl 5 bless behavior, and you want to tweak the order of
calls. So, you don't define a SETUP. BUT, the author of a module you're
inheriting from defined a SETUP, not to your knowledge? This gets called
automatically by bless(), with no way to override it, either making you
manually undo it all or decide not to subclass it anymore. This is bad.
I think the RFC would be fine intact with the change that a new keyword
"setup" should be added that:
1. Automatically blesses stuff
2. Recursively calls SETUP in the method described
That way, Perl 5 bless remains unchanged (good), and we get all the new
features Damian's proposing (also good). This RFC is a *big change*. I
think it deserves a new keyword.
-Nate
