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

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

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

> >
> > 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);

which will always call Dog::Dog(int) (or a promotable version), unless
this constructor has been marked 'explicit'.  Many people feel this
default should have been reversed: the constructor should only have been
called if marked 'implicit', i.e. the default is wrong.

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.

Hildo