On Wed, Aug 30, 2000 at 08:22:11AM +0100, Hildo Biersma wrote:
> > =head1 TITLE
> >
> > my Dog $spot should call a constructor implicitly
> >
>
> What, then, happens to the following code:
>
> my Dog $spot;
> if ($age > 12) {
> $spot = new Doberman();
> } else {
> $spot = new Corgi();
> }
>
> Would you seriously propose to create a Dog object, then wipe it in
> either branch if the if?
Considering that case, the RFC's language should be changed to say the
current meaning of my Dog $spot is to be replaced. I'm not sure if I meant
that originally, or if I mentioned it in the RFC, but considering the
potential ambiguity I don't see much alternative.
As for what happens, my Dog $spot calls the Dog constructor, and then later
you redefine it as a Doberman() or Corgi() object. Provided there are
checks in place, and those classes are not subclasses of Dog, you will
encounter errors, possibly fatal.
> Also, not every class of object can have a default constructor, not is
> that always desirable. Let's take a database handle as an example:
>
> my DBI::dbh $handle;
> if ($env eq 'test') {
> $handle = DBI->connect(... connect to test ...);
> } else {
> $handle = DBI->connect(... connect to prod...);
> }
In this case, then, DBI shouldn't provide an implicitly called constructor.
The my DBI::dbh $handle would then either raise a warning or error, or
$handle will simply be declared as a normal lexical.
Thanks for pointing out these cases, I will update the RFC accordingly Real
Soon Now.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
