> : 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?
>
> I'm not doing either of those things... :-)
Yayy! :)
> : Just for my vote, I want to be able to declare new properties, but
> : would rather not be able to accidentally set $o.ture.
>
> That's how it works.
Ok. So are we sticking with the
our property *foo;
syntax?
And does that mean property is a type? ~smirk~
> : 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 :(
> : }
> : . . . .
>
> None of those are legal if the object doesn't have the property yet.
> Only C<but> has the power to add roles at run time.
Which works as well for objects of class Foo as for undef. Ok.
But it only works if the property/role being added is one the compiler
already knows, in which case it just "promotes" the object to a new
pseudo-class with the new property. Yes?
> . . . .
> : That's beautiful, and very sensible. Where can I read up on roles a
> : little more?
>
> Well, it's not nearly as general as we're making it, but the
> inspiration for it comes in part from the "Traits" paper:
>
> http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf
This box isn't well configured, so I forwarded this to work. I'll see
it Monday.
> Basically, I'm attempting to take their concept and unify it with
> properties, interfaces, generics, aspects, and mixins. Among other
> things...
You have a talent for designing Swiss Army Knives. :)
> : But I thought properties *were* attributes, basically....
>
> We're using "attributes" to mean instance variables defined by the
> class. Properties used to be considered something else, but now this
> role-playing I'm talking about makes them more like real attributes
> that happen to be added at run time. Except it doesn't modify any
> named class to do so, but only the anonymous class associated with
> the object in question. (And if there isn't an anonymous class yet,
> it generates one.)
Wrapper-classes?
> : Hrmm. So properties are "object" attributes unrelated to class?
>
> Unrelated to the original named class.
On that note, just for curiosity -- does undef have a class?
> . . . .
> : 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 don't see what the problem is. Once anyone has declared *zippy,
> everyone has a global zippy, and it's the same global zippy
> everywhere. You only get separate zippys if in more than one place
> you say things like:
>
> our property zippy;
> my property zippy;
I was just saying that the compiler would bail if you said
module Foo { our property *zippy; }
module Bar { our property *zippy; }
( Hmm... I think I need to reread the rule on semicolons. :)
> Either of those declarations may be exported, however, in which case
> the importing modules shares the zippy, just as it would share an
> exported variable.
Ok, exported as in the Exporter module.
> . . . .
> : 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? :)
>
> Don't have a doc, but see Java for an example. Basically it's a
> clunky way of sneaking a little bit of multiple inheritance into a
> language that only supports single inheritance.
>
> Larry
Ok, if Java interfaces will do as an example/template, I understand,
and I *LIKE* it. In fact, I like it much better than Java (but then, I
always have. ;o)
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
