Damian Conway wrote:
* invoke some other hierarchy of automagic methods
(REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
REINCARNATE
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
Perl6 This RFC proposes that the second argument to Cbless be made
Perl6 mandatory, and that its semantics be enhanced slightly to cover a
Perl6 common, ugly, and frequently buggy usage.
Yes!
--
Randal L. Schwartz - Stonehenge
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
Perl6 This RFC proposes a new pseudoclass named CNEXT.
Perl6 This pseudoclass would provide a way of correctly redispatching a method
Perl6 or an autoloaded method.
Yes!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1
On Sat, Sep 02, 2000 at 12:16:48AM -0400, John Tobey wrote:
I agree with Michael that SETUP should be BLESS. You argue that it
Oops, I mean Nate. Sorry, Michael!
-John
Michael G Schwern wrote:
Derived classes will never have to override a base's implementation,
and all member variables should be private, and everyone will always
use an accessor, and the UN will bring about world peace, and as long
as I'm wishing for a perfect world, I'd like a pony. ;)
On 9/2/00 11:34 AM, Nathan Wiger wrote:
It doesn't seem that it's that hard to add a single line to your SETUP or
BLESS or whatever method that calls SUPER::SETUP.
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
The whole notion of blessing is non-obvious enough already.
It's the benedictory (con)not(at)ion of blessing, not the bless()ing
itself that so confuses people, I think.
It bless() were instead named something like
mark
stamp
label
brand
retype
denote
notate
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
private $self-{data} = $derdata;
should be $derdatum here?
Yes. Thanks.
Damian
I'm still not totally convinced that its so horrid to make the
File::LockAndKey DESTROY call $self-SUPER::DESTROY manually...
Believe me, it is in a large, deep, and/or MI hierarchy!
but it does break encapsulation.
Exactly.
If you can figure a way out of the dilema I
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 Sat, Sep 02, 2000 at 03:18:06PM -0400, Mike Lambert wrote:
In certain cases, like the one in which you
proposed, you'd want to explicitly bypass the parent DESTROY.
sub DESTROY {
my $self = shift;
$self-UNIVERSAL::DESTROY(@_);
}
would skip the automatic chaining because the
Also, its not entirely clear why method chaining is desired only for
constructor and destructors. What about every other method?
Constructors and destructors are special. They're not about *doing*
something; they're about *being* (or not being) something.
A "doing" method *may* wish to
13 matches
Mail list logo
