Damian Conway wrote:
>
> * invoke some other hierarchy of automagic methods
> (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
If we do go this way, then we should make sure any names follow suit:
BLESS REBLESS
CREATE RECREATE
INVOKE REINVOKE
SHAPE
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
>> t
> Damian Conway wrote:
> >
> > * invoke some other hierarchy of automagic methods
> > (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
REINCARNATE
> 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 implem
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
Perl6> This RFC proposes that the second argument to C 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 Cons
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
Perl6> This RFC proposes a new pseudoclass named C.
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.
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 au
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
>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 othe
Damian Conway <[EMAIL PROTECTED]> writes:
> > > But I agree that anything beyond that is simply horrible. You'll only
> > > drive more people *away* from OO, because it generates so horribly
> > > inefficient code. If you want a constructor called, than FGS *call* a
> > > constructor. Mayb
> > 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
> 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 prop
> > private $self->{data} = $derdata;
>
> should be $derdatum here?
Yes. Thanks.
Damian
> BLESS is still my top choice by far, because while it doesn't do any
> blessing, it's obvious what it's attached to.
I think it's misleading.
> Remember, PRINT and PRINTF don't have to do any printing, nor do
> POP, PUSH, etc, have to do any popping or pushing.
But SETUP *neve
> 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 C RFC out today.
> One thing nobody's brought up is this: What if you decide you want the
>
On 1 Sep 2000, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects : Private keys and methods
Here, here & amen, Damian! This one gets my instant vote!
David
On Sat, 2 Sep 2000, Nick Ing-Simmons wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
> > > > But I agree that anything beyond that is simply horrible. You'll only
> > > > drive more people *away* from OO, because it generates so horribly
> > > > inefficient code. If you want a constructo
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 c
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
On Sun, Sep 03, 2000 at 11:35:53AM +1100, Damian Conway wrote:
>> If you can figure a way out of the dilema I proposed above, I suppose
>> this makes sense.
>
> Easy. Don't let File::Lock::Mac inherit from File::Lock. Have it *delegate*
> to File::Lock instead. See my forthcoming C RFC.
> 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
> 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 t
26 matches
Mail list logo
