On Thu, 3 Oct 2002, Allison Randal wrote:
> On Thu, Oct 03, 2002 at 03:00:21PM -0400, Michael G Schwern wrote:
> > On Thu, Oct 03, 2002 at 02:46:38PM -0400, Michael G Schwern wrote:
> > > class ATV is Car, interface {
> >
> > Hmmm. That should probably be
> >
> > class ATV isa Car is interface {
>
> That's:
>
> class ATV is Car is interface {
I'd vote that properties be implemented as classes (see below), which
prompts the question, How does one distinguish between a property class
which inherits from another property class, and a property class which
'is' some property? Or perhaps there is no difference, because
property-ness is actually implemented via inheritance?
> We haven't finally decided how properties will be defined. They may be
> subs:
> they may be methods:
> they may be classes:
I came to the class implementation conclusion when thinking about runtime
properties. Things like "but tainted" obviously need to propogate when
operations are performed on them, so other properties, such as "but
true/but false", may want to propogate as well. However the rules for
propogating "tainted" (result is always tainted) are different from
true/false (propogate according to boolean logic) are different from
'but We_better_call_ya("Bruce")' (never, ever propogate).
So the obvious way to implement that is via operator overloading for the
property classes. If two values have properties of the same type, the
same operation performed on the values is performed on the properties.
5 but false + 3 but false == (5 + 3) but (false + false)
If only one value has a property, the right thing to do is not entirely
clear. Maybe in (5 but false + 3) the false property is combined with the
boolean conversion of 3 (true). Or undef if the conversion is not
possible. Or maybe I'm rambling on too long...
~ John Williams
