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
