On Sat, Sep 02, 2000 at 11:05:23AM +1100, Damian Conway wrote:
This bothers me. It leaves no way to override the behavior of a
parent's SETUP and DESTROY, you can only overlay. You mentioned that
this is normal for most other OO languages, so I presume there's a way
to deal
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 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
I can most certainly think of cases where a base class's DESTROY does
something a derived class doesn't like. Consider your example,
File::Lock. File::Lock::DESTROY calls flock($fh, LOCK_UN). I derive
File::Lock::Mac from File::Lock. Uh oh, Macs don't implement flock!
Under your
goes? Your logic suggests that I'd never want to meddle in the base's
implementation.
What happens when the base classes' author finally fixes the problem you
wrote around (and incidentally changes touchy implementation details in the
base)? What happens someday when you can't see 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
On Sat, Sep 02, 2000 at 03:13:17AM -0700, Matt Youell wrote:
What happens when the base classes' author finally fixes the problem
you wrote around (and incidentally changes touchy implementation
details in the base)? What happens someday when you can't see the
implementation of the base
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
Yes, welcome to the dirty, icky real world. Life sucks, people will
write bad code, you will have to inherit from it. Sometimes you have
to break a little encapsulation to make an omlet. I'd rather it was
not so, but its better to accept it and deal than deny.
Of
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Hierarchical calls to initializers and destructors
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number:
Furthermore, it proposes that both CSETUP and CDESTROY methods
should be invoked hierarchically in all base classes.
This bothers me. It leaves no way to override the behavior of a
parent's SETUP and DESTROY, you can only overlay. You mentioned that
this is normal for
=head2 Hierarchical CSETUP calls
It is proposed that when an object is blessed, Iall of the CSETUP methods
in any of its base classes are also called, and passed the argument list
appended to the invocation of Cbless. CSETUP methods would be called
in depth-first, left-most order (i.e.
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
=head1 ABSTRACT
This RFC proposes a new special method called CSETUP that is
invoked automagically whenever an object is created. Furthermore,
it proposes that both CSETUP and CDESTROY methods should
be invoked
On 9/1/00 5:44 PM, Nathan Wiger wrote:
sub SETUP {
my ($self, @ctor_data) = @_;
# initialization of object referred to by $self occurs here
}
Hmmm. I'm not sure if I like this. I like the *idea* a lot, but I must
say that I think I quite like RFC 171's approach better.
I haven't
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
Furthermore, it proposes that both CSETUP and CDESTROY methods
should be invoked hierarchically in all base classes.
This bothers me. It leaves no way to override the behavior of a
parent's SETUP and DESTROY, you can only
The typical constructor would then be reduced to:
package MyClass;
sub new { bless {}, @_ }
with initialization handled in a separate CSETUP routine:
sub SETUP {
my ($self, @ctor_data) = @_;
# initialization of object referred
18 matches
Mail list logo
