This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my Dog $spot should call a constructor implicitly
=head1 VERSION
Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 171
Status: Developing
=head1 ABSTRACT
The current optimization syntax my Dog $spot should be extended to call
some implicit constructor and create a Dog object out of the $spot variable.
=head1 DESCRIPTION
The current syntax is largely for optimization, forcing the programmer to
repeat herself when initializing an object:
my Dog $spot = Dog->new();
That call, in itself, is not overly onerous. Consider:
my Animal::Mammal::Dog $spot = Animal::Mammal::Dog->new();
Provided this RFC is adopted, this call can be changed to:
my Dog $spot = "Spot";
=head1 IMPLEMENTATION
The syntax resolves to a method call in the Dog namespace. This method is
called as if it were called as a class method with an optional argument (in
the case of assignment). For example, the syntax:
my Dog $spot = "Spot";
would be transformed to, or be the equivalent of:
$spot = Dog->$METHOD("Spot");
=head2 Constructor
All but the author-defined constructor suffer from the disadvantage of
potentially causing problems with current Perl modules.
=over 4
=item sub CREATE {}
As RFC 159 somewhat implies the syntax could resolve to the CREATE method.
=item sub NEW {}
Like CREATE, but maps a little more cleanly to the large body of modules.
=item author-defined
Allow the author to define an implicit constructor. This would be the most
flexible method, needing only one constructor to be defined (unless
semantics differ, of course), and providing B<no> backwards-compatibility
problems.
This definition would probably be best provided through a pragma:
use constructor qw(new);
perhaps even dropped on top of overload:
use overload constructor => 'new';
=back
=head1 MIGRATION
A my Dog $spot call should not be translated to the implicit method call if
an implicit method is not defined. That makes migration, in this case,
depend on implementation. If the CREATE or NEW methods are chosen as the
implicit method, any modules with these methods (which should be few to
none) would start experiencing odd errors. If the author-defined method is
chosen there will be no migration issue for modules, as any modules not
wishing for the interface will not have defined what method to use
implicitly.
Once module authors have defined suitable implicit methods there is an issue
with existing Perl scripts. The my Dog $spot = Dog->new() will become
redundant if the new() constructor does the same thing as the implicit
constructor. If the two constructors do different things, problems could
crop up. Additionally, if the module author is doing any sort of
class-level tracking based on constructor calls (perhaps counting the number
of constructor calls made) there will be two constructor calls to account
for.
This all depends on how widespread the my Dog $spot syntax has become. I
could not find an example of it in my 5.00503 or 5.6.0 documentation. I'm
not sure if it's Camel 3. If it is indeed under-documented the migration
will be easier. If it's deprecated in current perls the issue would become
moot by Perl6.
=head1 REFERENCES
RFC 107: lvalue subs should receive the rvalue as an argument
RFC 118: lvalue subs: parameters, explicit assignment, and wantarray() changes
RFC 132: Subroutines should be able to return an lvalue
RFC 149: Lvalue subroutines: implicit and explicit assignment
RFC 159: True Polymorphic Objects
