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

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