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

Jonathan Scott Duff wrote:
> 
> On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote:
> > First greatly stylistic compatibilty.  An inexperienced programmer would
> > see:
> > my Dog $spot = "Spot";
> >
> > And become confused.  It's totally unintuitive (at least so far as other
> > mainstream OO languages go).  It looks like Dog could be a type of String
> > subclass.
> 
> Why would the programmer become confused?  In C++ (a mainstream OO
> language), if a Dog constructor was defined that took a string as an
> argument, the string would be auto-converted to a Dog.
> 
> So, if this were adopted for Perl, the programmer would know that the
> class constructor for Dog would be called to instantiate $spot, then,
> because of the assignment, the Dog->STORE() method would be called.
> And if the programmer were inexperienced, it would be a perfect time
> for them to learn something.

Note that in C++ this can be sufficiently confusing that the 'explicit'
keyword is required to mark constructors as "do not use them for this
kind of behavior". 

Many people see even this as a bad choice, saying that 'explicit' should
be the default, and that C++ constructors should be marked 'implicit'
for this behavior to be allowed.

Anyway, what's wrong with:
  my Dog $spot = Dog->new("Spot");
as that scales to
  my Animal $spot = Dog->new("Spot");
  my Dog $fifi = PersistentDog->restoreFromDatabase("fifi");
and others - i.e., it does not impose policy on the poor user.

Hildo