--- Smylers <[EMAIL PROTECTED]> wrote:
> Larry Wall writes:
> 
> > :     if $x.foo { print "$x has property foo" }
> > :     $x.bar = 1;   # Or $x = $x but bar
> > 
> > Or maybe the .bar notation is only for rvalues, and to create a
> > property you have to say:
> > 
> >     $x but= bar;
> 
> I think that would be an unPerlish restriction; people who know
> how to read a property would also expect to be able to set it in
> the same way.

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;

> > ... as long as we limit the .bar notation to rvalues or to
> > lvalues on already-created properties.  And in fact, we may
> > be limiting the creation of properties to predeclared names,
> 
> That sounds like a much better solution.

Agreed.

> And thanks for taking the time to answer Luke's questions so fully.
> Smylers

Ditto. :)

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

Reply via email to