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
