--- Larry Wall <[EMAIL PROTECTED]> wrote:
> 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. :-)
lol -- good. :)
I'm all for there being more than one way to do it, and for not playing
Code Police (God knows I'd do my share of time in the BigHouse...), but
I have to agree with you on this one.
> : 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.
Ah -- implicit adoption by the new foster parent. That's kind of neat,
but it confuses me. Does that mean you're leaning more toward allowing
undeclared properties, or just that you're still trying to give both
sides of the argument thorough consideration?
Just for my vote, I want to be able to declare new properties, but
would rather not be able to accidentally set $o.ture.
> : 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.
The adoption mentioned above handles this, but even though properties
cut across class lines, I want to avoid those silly boo-boos.
While
if $me.flying {
$me.drunk = "scotch"; # inebriation source
$me.dunk = true; # I do when I can
$scotch.dunk = "fig newton"; # the only acceptable value!
$newton.dunk = true; # only way I eat 'em
$scotch.drunk = true; # oops, it's all gone :(
}
might be all well-and-good, I don't want my $newton to be able to be
set <C>$newton.drunk = true</C> by accident because in all that
pseudo-repetitive code I mistyped and the compiler let me get away with
it. Code bits like this are common enough that I want every bit of
assistance I can get.
I'd rather be able to add the .dunk and .drunk properties to classes in
which they are appropriate, even after the fact of the class
definition, but I definitely don't want that to make it possible to
drink my $newtons, nor get them inebriated.
Am I too far over the edge here?
> : 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.
Okie.
> 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.
That's beautiful, and very sensible. Where can I read up on roles a
little more?
> : 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.
True, which is why I want to learn more about them, lol.
I need to get started making my mistakes in virtual code now, before I
start writing real P6 code, so I can get over the hump in the learning
curve. :)
> : 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 {...}
"does" rings a bell. :)
But I thought properties *were* attributes, basically....
Hrmm. So properties are "object" attributes unrelated to class?
Ok, floundering again. Lemme think this through.
my $x = undef but true;
undef is a value. $x is just a joe scalar. No class, no "real" object.
I get that. We're just fiddling with the details of $x's value, and
assigning the globally available property of true to it so that
print "foo" is $x;
will print, even though it's value is undef. So far so good.
Now, I want to say
my $y = undef but zippy;
The compiler politely tells me that zippy isn't valid, and that perhaps
I should RTFM. Ok, that's good, but I really want to be able to return
a zippy undef as a response to those impertinent sub calls, so that I
can both refuse to talk to them and still have a zippy response,
effectively having my cake and eating it, too.
Such wittiness requires a little forethought, though.
I have to predeclare what exactly I mean by "zippy", or at least
generally enough that the compiler deems it a valid comeback.
See? I'm catching up.
I'll get back to this in a bit.
> 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.
Ok. So
our property *true;
makes sense out of class context, and can be overwritten by explicit
class values for true, but
our property *zippy;
would probably be a bit foolish, since there can be only one such, and
trying to redeclare it by loading two modules with that in them would
crash, but wouldn't storing the context of a property by like
recursively giving the properties some properties of their own? Is that
a can of worms we really want to open?
> 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.)
All I've seen on interfaces is a few lines in passing. Anyone got a
reference where I can RTFM and thin the spam to the list? :)
> : > And thanks for taking the time to answer Luke's questions so
> : > fully.
> :
> : 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
lol -- I'll keep praying for ya, and I'm sure I'm not alone.
And please, I don't need any *increase* in my appreciation of calorie
intake!!! >:o)
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
