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 called on object creation
> 189: constructor called on object blessing
The difference is that bless is normally used within the classes themselves
(or not at all if leveraging UNIVERSAL::new) while my Dog $spot is in "user
code" all over the place. "my" is much farther from being a constructor
then "bless" is, IMO (given Perl 5's OO model anyway.)
> Both of them suffer from involuntary method calls and no way to prevent
> them.
If you think you need a way to prevent this mechanism, then you're basically
against it being part of Perl 6. The inability to make these types of
decisions is what maded Perl 5 OO what it is today, for better (lots of
flexibility), but mostly for worse (tedious, incompatible, and often buggy
bookkeeping swept under the carpet of the programmer; inability to optimize
"common" idioms internally because they're just common, not "standard";
extra layer of overhead for modules that do this heavy lifting for you, etc.
etc.)
I think these decision can and should be made for the good of Perl 6.
(see RFC 126)
> I like the *idea* to a lot. But I don't like the hooks being in bless.
> What if you want to bless something but not call all its cascading
> SETUPs? I'd much rather the hooks be somewhere else, like new builtin.
> Maybe 'setup'?
>
> sub new { setup {}, @_ }
If not in bless, then it should be in whatever the blessed (heh) object
construction system is in Perl 6. Adding another builtin seems silly to me,
though. When do you want to call bless outside of a constructor?
Re-blessing willy nilly may be neat, but the need to do so is usually
indicative of some sort of design problem.
-John
