Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

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