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

On Fri, Sep 01, 2000 at 12:20:34PM +0100, Hildo Biersma wrote:
> Michael Fowler wrote:
> > 
> > On Fri, Sep 01, 2000 at 08:31:17AM +0100, Hildo Biersma wrote:
> > > My previous concerns have not been adressed:
> > > - There may not be a default constructor
> > 
> > If there is no implicit constructor method defined by the class, and the my
> > Dog $spot syntax is used, a fatal exception is raised.  The RFC mentions
> > this.  This exact thing is also currently being discussed.
> 
> In OO vocabulary, a 'default constructor' is one that has been declared
> to take no arguments.  If a class defines a constructor that requiers
> arguments, it cannot be called implicitly.

This is not true.  In C++, if a class constructor that requires a single
argument is defined, and without the keyword explicit, it can be called
implicitly in type conversions.

However, I fail to see how this definition of 'default constructor' makes it
a requirement that there be one.  There must be one for my Dog $spot to not
raise a fatal exception, but if it's not defined and my Dog $spot is never
used, there is no requirement that there be an implicit constructor.

 
> > > - This makes creations of Singleton classes impossible
> > 
> > In what way?  The implicit constructor method can return anything it likes,
> > just as current constructors can.
> 
> Singleton classes can have a private constructor, and a class method
> that conditionally invokes the constructor _once_, then re-uses the
> reference when this makes sense.  That does not make the class method
> the constructor - and there might be multiple, different, of these class
> methods.

my Dog $spot does not preclude the use of explicit constructors.  All it
does is call a constructor implicitly.  I guess I still fail to see how this
makes singleton classes any less possible than current Perl makes them.


> > 
> > > - There is a good reason to created typed, but undef, references
> > >   and fill them in later.
> > 
> > What is this reason?  Can you give some examples?
> 
> You need to be able to create a scoped and typed object reference that
> starts out undefined, then is filled in depending on various arguments,
> and then is used safely afterwards.
> 
> sub BuyDog {
>     my ($budget, $age) = @_;
> 
>     my Dog $retval;
>     if ($budget > 100) {
>        $retval = ExpensiveDog->new( ---- blabla ---);
>     } elsif ($age > 12) {
>        $retval = BigDog->new(--- blabla ---);
>     } else {
>        $retval = MangyDog->new(--- blabla ---);
>     }
>     $retval->feed();
>     fill_in_forms($retval);
>     return $retval;
> }
> 
> >  Could such a thing fit
> > cleanly and unambiguously in with the rest of this idea?  If so, do you have
> > an idea how?
> 
> I think not - creating objects implicitly is *wrong*, unless we start to
> allow creating Objects on the stack, such as C++ does.

Well, I've been giving examples of using:

    my $spot isa(Dog);

today.  This does fit cleanly and unambiguously.

As for creating objects implicitly, this doesn't do that.  The constructor
is called implicitly, the my Dog $spot syntax is fairly explicit.


> > >
> > > Based on my C++ experience, this should only be allowed if the
> > > constructor has been marked as 'implicit construction safe'.
> > 
> > It is assumed that the method is "implicit construction safe", if by that
> > you mean suitable to be called implicitly to construct an object.  Since the
> > methods are uniquely named, or specified by the author, I don't think this
> > is assuming too much.
> 
> Let me reiterate.  One of the issues in C++ is that
> 
>   Dog spot = 5;
> 
> means 
>   
>   Dog spot = Dog(5);

Actually, it's:

    Dog spot;
    spot.overload=(5);

assuming there's an operator=(int) defined.  If there's only a Dog(int)
defined, and an operator=(Dog), then yes, the 5 is implictly converted.

I am not proposing we implement implicit conversions.

 
> Merely naming a method as a constructor does not mean implicit object
> creation is a good idea.  Creating objects can be quite expensive, and
> one of the biggest drags on program performance is unexpected object
> creation.

Is getting an object out of my Dog $spot unexpected?  What about if you were
to forget what my Dog $spot means currently?


Michael
--
Administrator                      www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--