I see two problems with that. First, what if you want a typed variable that's empty?

my Dog $spot; # new Dog

my Dog $dog = $spot; # oops - create a Dog just to destroy it
[download]

The other problem I see with making that change is that every use of my winds up with run-time overhead to call attributes::import. If you limit it only to my statements with types, that might be OK, but the more general case would suggest that my $rover would call attributes::import in the current package with an empty list, too.

In either case, I think it's too much overhead for the sake of some nice object constructor syntax.

That said, ++ for cool exploration of attributes.pm. That attributes as constructor trick might be useful for quick-and-dirty generic objects with dynamically-generated accessors.

my Object $soldier : name rank serial_no;

$soldier->name( "Damian" );
[download]

Objection 1: Well, don't do that ;-) Even though my Dog $spot; looks like strong typing, it isn't. Following with my $dog = $spot; accomplishes exactly the same thing without the constructor call, which is . . .

Objection 2: I agree that the price is too high if allowing the import call for an empty attribute list hurts the performance of vanilla my calls. There appears to be a place in the lexer for my Dog $spot;, and with the death of pseudohashes that ecological niche is empty. Since attributes.pm has already absorbed part of it, it seems natural to extend the rest that way. If the pseudohashes' use for that kind of statement didn't interfere with vanilla my, then it seems likely that this wouldn't either. That remains to be seen, though.

As for the rest, thanks for the props. I agree that that kind of generic object would be easy to generate this way. I'm not a big fan of that sort of thing, though. Without any methods but getters and setters, those classes just look like hash data to me.

Let me expand a little about dynamic strong typing. That's what's behind my interest in this little hack.

The declaration my Dog $spot; doesn't really implement any kind of strong typing. It just looks that way to C++ and Java slingers. A strong dynamic type system for perl needs a little more than that.

Dynamic strong types require a great deal of expensive monitoring and testing at runtime. They can't rely on static checking, like C++. It should be optional in Perl, and you shouldn't pay for it if you don't use it. You shouldn't use it if you don't need it.

I'm working on a follow-on to Tie::Constrained, one which will be a base class for dynamic strongly-typed classes of all kinds. Instead of my Foo $foo; making $foo a Foo, it can tie $foo in a way that makes sure it subsequently remain a Foo. Attempts to assign non-Foo's to $foo will meet sudden death (or something).

That's why I'm interested in this syntactic sugar. The tie interface is ugly and obscure. A constructor-like interface makes people expect a regular weakly-typed object. For a strongly typed Dog class, my Dog $spot; looks exactly like what it does -- makes an uninitialized but indisputable Dog.

That's what I'm really trying to do. An optional, per-variable, pay-as-you-go strong type system for Perl.

It can detaint, too.

After Compline,
Zaxo

Let's not forget that while native phash syntax is going/gone, phashes still exist in the form of use fields. IIRC, you still need to use the my Dog $spot syntax if you want compile-time checking of field based classes.

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

Well, the reason why attributes::import is not called in a statement like my Dog $spot is because IIRC the syntax my Class $var was originally created for things like compile-time field checking of psuedohashes. The attribute thing came later.

My first "A-ha!" moment of the morning - I have some old code I maintain that does exactly that my Dog $spot; thing, and has pseudo-hashes - now I know the reason ! - I always thought it was because the original author of the code was a Java programmer feeling homesick...

...reality must take precedence over public relations, for nature cannot be fooled. - R P Feynmann

I can't comment on Damian's spiel; I've never heard it. I'd appreciate a link if he's published it somewhere.

I think you're right about leftovers, and that's encouraging. An empty niche in the lexer ecology is just begging to be filled. It wouldn't be there if it interfered too much with vanilla my declarations (per xdg's second objection, above).

After Compline,
Zaxo

Here's a Dog class which admits dynamic strong typing/value types, like I suggested in my replies to xdg and TimToady.

package Dog;

use Tie::Constrained;
use Scalar::Util qw/blessed/;

# constraint object
my $is_a_dog = Tie::Constrained->new(
    sub { blessed $_[0] and $_[0]->isa('Dog') },
);

sub new {
    bless {}, shift;
}

# not a constructor this time, ties the referent
sub MODIFY_SCALAR_ATTRIBUTES {
    my $class = shift;
    my $ref   = shift;

    tie $$ref, 'Tie::Constrained', $is_a_dog;

    # ignore attributes for this example, but
    # must have one to get called
    ();
}

sub bark {
    my $self = shift;
    print "Woof!\n";
}

package Cat;

sub new {
    bless {}, shift;
}

package main;

my Dog $spot : Generic ;

eval {$spot->bark}
    or warn q(Only tangible Dogs bark, ), $@;
eval {$spot = Cat->new}
    or warn q(Can't be a Cat, ), $@;
eval {$spot = Dog->new}
    or warn q(Major malfunction: ), $@;
eval {$spot->bark}
    or warn q(Only tangible Dogs bark, ), $@;
[download]

Only tangible Dogs bark, Can't call method "bark" on an undefined value at dog.pl line 42.
Can't be a Cat, Constraint violation: at dog.pl line 44
Woof!

Declared attributes would likely be stored in %{tied($spot)}, which is persistent and independent of whatever is assigned the name. Matching declared attributes with Dog instance ones could be part of the constraint.

This is a very rough proof of concept. I haven't tried to make my $spot : Watchful = Dog->new; do the right thing. I haven't checked if it plays nice with fields.pm or Attribute::Handlers. I'd be surprised if it did at this stage.