Nathan Wiger <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> >
> > > First off, I think everyone is reading this RFC with the wrong mindset,
> > > forgetting the concept of embedded objects in Perl 6.
> >
> > Ah, that dumb idea again.
>
> Well, if you disagree with this idea, you probably won't agree with much
> else I have to say on this subject. Just calling something "dumb" isn't
> very productive, though. Maybe an explanation of *why* you think it's
> "dump"? Who knows, you might convince me and all the other "loons" that
> want vtable stuff in core...
Ah... <light dawns>... from reading further down I think I finally
understand where you're coming from with that RFC and it's not as dumb
as I thought it was, though I still wonder what happens when you
assign a 'Dalmation' to a 'Dog' shaped variable.
> > But you're creating the wrong bloody thing. And then you're throwing
> > it away. Now that's what I call a win. In this scenario what will
> >
> > my Dog $spot;
> > print defined($spot)
> >
> > return? If it's *not* 'undef' there'd better be a bloody good reason
>
> This should definitely return undef.
That's not the impression I got from reading Michael's RFC.
> > See that
> >
> > my Dog $patches = $dog_factory->make_me_a_dog
> >
> > That's a factory method that is, returns a Dog of some sort, but you
> > don't know of what breed.
>
> Ok, then again I don't see what your problem with this RFC is.
Because C<ref($patches)> could easily be 'Dalmation'.
> Maybe Michael and I are on different wavelengths,
Actually, I think you may be.
> so I don't want to rewrite his RFC involuntarily through this
> discussion. *MY* take on CREATE is that it's all taken care of for
> you, unless you override it, in which case you can do special stuff.
> Increased flexibility, but doesn't get in the way. Don't use it if
> you don't want to. Just like DESTROY.
>
> -Nate
