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

[Piers Cawley]

Nathan Wiger <[EMAIL PROTECTED]> writes:

> 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.

> I believe the idea would be that CREATE is a *fundamental* method, like
> DESTROY, that would do basic declaration, creation, allocation, etc. So:
> 
>    my Dog $spot;
>    print ref $spot;    # 'Dog'
>    $spot = new Dalmation;
> 
> No reason this wouldn't still work. The term 'constructor' here is
> misleading. 'creator' is what I prefer, and that's also why I prefer
> CREATE.

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,
otherwise:

    package Hades;
    { 
        my Dog $cerberus; #There can only be one
       
        sub get_guard_dog {
            $cerberus ||= Hellhound::ThreeHeaded->new(name =>
                                                      'Cerberus');
            return $cerberus;
        }
    }

Doesn't work. Nor does any other creator of singletons come to that.

> >   - Makes factory methods impossible.
> 
> A little clarification on what specifically constitutes a "factory
> method" would be great.

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.

-- 
Piers