[% setvar title my Dog $spot should call a constructor implicitly %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/


my Dog $spot should call a constructor implicitly


  Maintainer: Michael Fowler <michael@shoebox.net>
  Date: 29 August 2000
  Mailing List: perl6-language-objects@perl.org
  Number: 171
  Version: 3
  Status: Retracted


The consensus was that my Dog $spot should simply be an assertion that $spot isa Dog, and nothing more (see RFC 218). In fact, nobody truly agreed with this RFC, or me.

That is not to say I still don't like the idea. I still think it's an intuitive and simple approach to object creation, moreso than any alternatives offered.


The current optimization behaviour of the syntax my Dog $spot should be replaced with a call to some implicit constructor, which creates a Dog object out of the $spot variable.


What is currently an optimization for pseudo-hashes:

    my Dog $spot = Dog->new();

should be replaced with:

    my Dog $spot;

which calls an implicit constructor (discussed further in the IMPLEMENTATION section). The optimization behaviour can be retained in some form (see the MIGRATION section).

This syntax can also be extended to provide a more robust constructor, allowing the specification of arguments:

    my Dog $spot (color => "brown", name => "Spot", answers_to => "yo dog!");


This is most readable and useful when declaring types, as in:

    my int $i = 4;
    my float $f;

And could be extended into lists, arrays, and hashes:

    my int ($x, $y, $z);
    my float ($price, $tax) = (4.90, 0.04);
    my array_ref @matrix;       # list of lists
    my int %counters;           # hash of integer values, possibly optimized


my Dog $spot resolves to a method call in the Dog package. 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");

If the multi-argument form of the constructor were to be adopted this would have to change. Dog->$METHOD would either have to return a tied scalar, thus being the equivalent of:

    $spot = Dog->$METHOD();

Or RFC159 would have to be adopted, producing the equivalent:

    $spot = Dog->$METHOD();

And, finally, the syntax:

    my Dog $spot (@args);

would be the equivalent of:

    $spot = Dog->$METHOD(@args);


Listed below are constructor alternatives. If a sub is chosen (as in sub PREPARE {}) it will suffer from the disadvantage of potentially causing problems with current Perl modules.

If an appropriate constructor is not provided a fatal exception should be raised when the syntax is used.


All current my Dog $spot constructs will have to be converted to simply my $spot.

The optimization provided by the current syntax could be retained, in a slightly different form. If an object is constructed using my Dog $spot compile- and run-time checks could be put in place to force the $spot object to always be blessed into the "Dog" package, raising a fatal exception if this promise is broken in any way.


    version 3
        - changed status to "Retracted", added a NOTES ON RETRACTION section
        - removed the $METHOD {} suggestions
        - fixed the tied scalar example

    version 2
        - made it a little clearer that this is to replace the current
          meaning of the syntax
        - replaced the MIGRATION section with better migration method
        - added a PREPARE constructor alternative
        - made a distinction between sub $METHOD {} and $METHOD {} in the
          constructor alternatives list
        - added a suggestion for the list argument form of the constructor,
          with some alternatives to the my Dog $spot if it's adopted
        - added some examples of what the syntax could be useful for
        - removed lvalue RFC references that shouldn't have made it into v1,
          added some p5p archive references
        - added this CHANGES section


RFC 159: True Polymorphic Objects

p5p archives -- each link is the start or continuation of the discussion

my Number $n www.xray.mpe.mpg.de www.xray.mpe.mpg.de www.xray.mpe.mpg.de

[PATCH 5.005_62] my Dog $spot and prepare www.xray.mpe.mpg.de www.xray.mpe.mpg.de

RFC 218: my Dog $spot is just an assertion