I'd think that would depend on the current status of strictures.
Assuming no strictures at all, I'd rather expect Perl to autovivify
properties much the way hash elements are created when you assign a
value to a previously nonexistant key, but that's exactly the reason I
*NEVER* leave strictures *or* warnings off, even in short little
one-shot programs. If it's complex enough to save to a file, it's worth
adding a couple of "use" statements to make sure I don't do something
carelessly stupid.

And if I try to set $o.bar when there's no bar property predefined on
class Foo of which $o is a member, does that mean this singular object
gets this new property, or does Perl have to redesign class Foo on the
fly, and suddenly distribute a bar property across all Foo object
extant? Does it imply a scalar type from your supplied value of 1? What
if you later try to "push $o.bar, 2"? Ugh.

Accordingly, I'd expect Perl to stick out it's tongue, cross it's arms,
and refuse to play with me if I tried to set a property of which it was
not previously aware. Personally, I'm a little scared of how this would
work without strictures on. The DWIMmyness we expect from Perl would
beat the dickens out of any possible optimization, though that's going
to happen a lot with unstrictured code anyway....

On the other hand, properties are probably best scoped to a class, and
a class definition is almost always best placed in a class file, which
has strictures on by default. Again, I recommend some syntax
class-scoped and compile-timed to declare properties, such as

  class Foo has Array bar is rw = undef;

Agreed.

Ditto. :)

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/