> 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 C RFC out today.
> One thing nobody's brought up is this: What if you decide you want the
>
> > 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 e
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 othe
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 i
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
> 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 s
What happens on reblessing?
--tom
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: constr
> What if you want to bless something but not call all its cascading
> SETUPs?
Then don't *define* cascading SETUPS in the first place. :-)
C still would have the existing Perl 5 behaviour. Things
only change if you add these new-mangled SETUP methods.
The point of welding SETUP calls to
> 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: construc
10 matches
Mail list logo
