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

Michael Fowler <[email protected]> writes:

> On Fri, Sep 01, 2000 at 09:34:12AM +0100, Piers Cawley wrote:
> > Because, hopefully, there are efficiency gains to be had when perl
> > *knows* that $self is a Dog. If it only makes the 'name' method
> > call work faster then it's a good result. Admittedly 'bark' is a
> > fairly simple function method with only one other method call, but
> > in more complex methods one would expect efficiency gains.
> 
> Here, I think, is the primary reason for your email. You want my Dog
> $spot to retain it's optimizational (!) behaviour. I'm proposing we
> put a different meaning in place. This doesn't mean the optimization
> goes away; we can probably still do optimization in many of the
> cases you cite, especially if $ME or self() get adopted.

Are you wilfully misunderstanding me? Let's try another possible
example to see if you get the point:

    print "What sort of dog do you want? ";
    my $dog_type = ucfirst(<STDIN>); chomp $dog_type;

    try {
        my Dog $puppy = "Dog::${dog_type}"->new(name => $dog_name);
    }
    catch Exception::BadType {
        croak "Dog::${dog_type} is not a valid breed\";
    }
    catch {
        croak $!;
    }

I want 'my Dog $spot' to enforce the condition that:

    (!defined($spot) || $spot->isa('Dog'))

And that is all. I *really* don't the idea of implicit object
creation. Consider other OO languages; C++ has implicit object
construction, but has added the explicit and implicit keywords to
enable the programmer to turn the behaviour off. Not having actually
programmed in C++ I don't know how often you want to do this, but the
fact that the functionality is informative. In Java, on the other
hand, the designers looked at C++ and decided *not* to do implicit
construction. 

> I've tried to clear up the ambiguity that my Dog $spot still has an
> optimizational meaning in v2 of the RFC; it doesn't, necessarily. It
> means "$spot is a Dog object, call the constructor and instantiate
> it as such". I would very much like to know how successful I was.

But $spot could easily be a Dalmation object that you are using like a
Dog in the current context. Maybe I should just write a counter
proposal along the lines of:

=head1 TITLE

C<my Dog $spot> should simply assert that
C<(!defined($spot) || $spot-E<gt>isa('Dog'))>

And let them duke it out.

-- 
Piers