On Sat, Nov 29, 2003 at 09:13:32AM -0800, Paul Hodges wrote:
: --- 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.
I don't feel any great need to de-stricture this in non-strict scopes.
I think people who want hash semantics can use hashes. :-)
: 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,
Yes, in fact it gets a new anonymous class that is derived from its
current class.
: or does Perl have to redesign class Foo on the
: fly, and suddenly distribute a bar property across all Foo object
: extant?
No, the whole point of properties is that they cut across class lines.
It doesn't matter whether you're flying first class or coach, you
might acquire the property "drunk" at run time.
: Does it imply a scalar type from your supplied value of 1? What
: if you later try to "push $o.bar, 2"? Ugh.
If we allowed undeclared properties, it'd have to assume scalars. But
if we require declaration of properties as a kind of role, then the
role declaration could declare whatever data structure it wants. In
fact, a role can declare multiple attributes, which implies that we
could conceivably have complex struct-like properties:
return undef but error(ENOMAKESENSE, "What the heck?", 42);
Under the hash view of properties, that has to be a scalar reference
to an object, but under the role view, it can merely be a set of
components of the undef object without a separate scalar existence.
Q: Mr. Undef, are you an error object?
A: No, but I play one on TV.
: 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....
I think roles are something we don't want to force novices to learn about
until they're ready for it. They can use existing roles without understanding
what they're doing, but they shouldn't go around creating roles, just as
they shouldn't go around creating objects without knowing what they're
doing.
: 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;
No, if you're gonna force people to declare properties in association with
a class, then they're no different from attributes. The whole point of
properties is that they're bound to an object independently of class
definition. You *can* incorporate them into a class explicitly, of course,
since they're just roles:
class Foo does bar {...}
For example, any class that wants to cache its boolean value might say
class Fancy is Simple does true {...}
Then it can recalculate its boolean value only when it needs to, rather
than every time the object is used in a boolean context.
I didn't mention it in my previous article, but roles are also a
generalization of interfaces. That is, interfaces are a degenerate
case of roles, when the role doesn't supply any implementation, which
forces the class incorporating the role to supply an implementation.
(Property roles don't fall into this category because the implied
has $.bar is rw;
also implies the .bar accessor to it, which is all the implementation
it needs.)
: > > ... 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. :)
You're very welcome.
I'm just grateful that I feel up to it physically. If you ever want to
increase your appreciation for the simple acts of eating and drinking,
try doing without for a couple of months...
Larry
