in reply to my Dog $spot;

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]

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^2: my Dog $spot;
by Zaxo (Archbishop) on Jun 07, 2006 at 07:19 UTC

    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

[reply]

      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. :-)
[reply]
[d/l]
[reply]

In Section Meditations