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
On 9/2/00 12:12 PM, Nathan Wiger wrote:
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 { ... }
Sure, but does setup() bless? That's the question... :) In other
So, you don't define a SETUP. BUT, the author of a module you're
inheriting from defined a SETUP, not to your knowledge?
No worse that the current situation in which you have no clue what the
guy you're inheriting from expects. Better to have SETUPs called
below you than to not even
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.
There is. I'll try and get the Cuse delegation RFC out today.
One thing nobody's brought up is this: What if you decide you
On 9/1/00 8:02 PM, Nathan Wiger wrote:
I haven't commented on RFC 171 because I assumed it would be shot down
quickly by the Major Contibutors(tm), but let me just say now that I'm
firmly in this camp:
Funny, I don't see much difference between RFC 171 and this RFC:
171: constructor
What happens on reblessing?
An excellent question, and one that has been exercising my mind for
some time now.
I have come to the conclusion that a reblessing must either:
* invoke the old class's DESTROY(s) and then invoke the
new class's SETUP(s), or
* invoke
I haven't commented on RFC 171 because I assumed it would be shot down
quickly by the Major Contibutors(tm), but let me just say now that I'm
firmly in this camp:
Funny, I don't see much difference between RFC 171 and this RFC:
171: constructor called on object creation
189:
What if you want to bless something but not call all its cascading
SETUPs?
Then don't *define* cascading SETUPS in the first place. :-)
Cbless still would have the existing Perl 5 behaviour. Things
only change if you add these new-mangled SETUP methods.
The point of welding SETUP
On 9/2/00 12:16 AM, John Tobey wrote:
Every base's SETUP gets the same argument list? That seems highly
undesirable from an OO-purity standpoint. Or do you have a syntax for
member initializer lists in store for us?
I've been thinking about this too. I want some sort of decision to
save us
