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