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

Michael Fowler <[email protected]> writes:

> On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote:
> > And then there's:
> > 
> >   - Makes factory methods impossible.
> 
>     my Dog $spot;
>     my $pub = $spot->procreate;
> 
> Sure looks like a factory method to me.  Just because you don't get to say
> my Dog $pup for some optimization doesn't mean they're impossible.

Given that C<my Dog $pup> would appear to be (currently) the only way
to get any optimization at compile time then I submit that the ability
to optimize all method calls at compile time by declaring typed
variables for stuff is *far* more important than the questionable
gains to be had from implicit instantiation. I can think of *far* more
occasions where I want the optimization than occasions where I don't.

Maybe a compromise along the lines of:

   my Dog $spot = LIST; # $spot = Dog->new(LIST)
   my Dog $patches;     # $patches is undefined but we assert that
                        # it'll be a Dog. (Whether you can do
                        # $patches->new is left as an exercise)

Where the first element of LIST is not a Dog. If you want to
autocreate a null object then you can do C<my Dog $spot = ()>


> 
> 
> >   - Conveniently forgets all about polymorphism.
> 
>     package Mammal;
> 
>     sub hair_color { ... }
> 
> 
>     package Dog;
>     use base qw(Mammal);
> 
>     sub CREATE { bless({}, "Dog") }
> 
> 
>     package main;
> 
>     my Dog $spot;
>     $spot->hair_color("blue");  # works just fine

That's not polymorphism, that's inheritance.

Polymorphism is: 

    try { 
        ....
    }
    catch Exception::SelfHandler {
        $!->handle_self
    }

Note that in this context C<Exception::SelfHandler> is an abstract
superclass. The precise behaviour of the handler is defined by its
subclasses.

Another example:

    package MailorderPetshop;

    sub make_ad {
        my MailorderPetshop $self = shift;

        $self->stock_iterator->reset;

        try {
            STOCKLOOP: while (my Pet $pet = $self->stock_iterator->next) {
                print $pet->describe, "\t", $pet->price;
            }
        }
        catch Exception::WrongType {
            # Oops, we're not looking for cages etc, skip that
            next STOCKLOOP;
        }
    }

Again, the various C<$pet>s are instances of classes which are
subclasses of Pet, but in the context of the C<make_ad> all we care
about is that they are pets.
        
> I'm not proposing revamping the entire OO system, and I'd like to know what
> made you think I was.

No, but you are proposing the removal of a behaviour which has the
potential to be *very* useful when it gets better optimized, in favour
of something of questionable benefit. However, see my suggestion at
the top of this reply for something that may prove to be a useful
compromise.

Also, if you're really proposing this as a way of saving typing,
consider the idea that got floated on p5p a while back:

    use shortcut;

    with Long::Package::Base;

    my ::Dog $spot = ::Dog->new('Fido');

Which has the advantage of being useful all over the place...

-- 
Piers