FEATURE_INHERITED_PARENTSCRIPTS

[monte]

Hmm... I'd assumed it wouldn't really be a true mix in. Just an ordered list of behaviors on an object so the inhertance path would go:

object
behavior 1
behavior 1's behavior 1
...
behavior 1's behavior n
....
behavior n
object parent etc

[mwieder]

...a little hard to get a picture of that from the description, but it sounds like you're putting "behavior 1" and "behavior n" at the same level. And that's how I picture multiple inheritance working (or not working). How would prioritization work there? Let's say all the behavior objects have a "version()" function in them and the main object doesn't. If you ask for the version of the main object, which one would you get?

[monte]

Sorry... not at the same level... that's the opposite of what I was intending to say. The behaviors would be an ordered list so there really wouldnt be much difference between:

Code: Select all

set the behavior of object 1 to object 2
set the behavior of object 2 to object 3

and

Code: Select all

set the behaviors of object 1 to object 2&cr&object 3

The only difference is object 2 wouldn't always need to inherit from object 3...

[LCMark]

As Monte says it would just be a prioritized list so if you have the following arrangement:

Code: Select all

Object
      Behavior 1
      Behavior 2
        Behavior 3
      Behavior 4

The message order would be:

Code: Select all

    Object
    Behavior 1
    Behavior 2
    Behavior 3
    Behavior 4

As I said above, this could be a useful feature to allow 'mix-in' type functionality - particularly with before and after handlers. For example, you could have a custom tool-tip behavior, a behavior that logged actions - all kinds of things. Certainly it gives the scripter the power to tie themselves in knots if the behaviors overlap in their functionality - but then that's just a case of using the feature appropriately and designing carefully.

[monte]

@runrevmark... each of those behaviors could have their own inheritance path of parent behaviors too... I assume you would follow the complete inheritance path for each behavior before moving to the next behavior...

[LCMark]

@monte: that was a formatting fail (corrected now!) - yes the inheritence chain would be followed for each behavior in turn.

[monte]

Ah... I did wonder why you had the same list twice

[mwieder]

Coming into this late, I can only guess at what it looked like before.
But the message inheritance for the mixins makes sense.

I'd also like to suggest that "the behaviors" be a synonym for "the behavior" as we move into this space, to allow for the cases of

Code: Select all

put the behaviors of control x
set the behavior of control x to

where either "behavior" or "behaviors" would use a cr-separated list.
And can we please "set the behavior to the object" rather than "to the long id of the object"?

[LCMark]

Do we need to make a synonym there? You don't say 'his behaviors were unusual', you say 'his behavior was unusual'; this seems to suggest setting the behavior of an object to a list makes as much sense as setting the behaviors of an object to a list...

In regards to:

Code: Select all

set the behavior of control x to <object>

Then, no, that isn't possible. Set is a command that takes a property and an expression - what the property is doesn't matter to it. It evaluates the expression, then calls 'setprop()' using it. When an object chunk is evaluated in expression context it either throws an error (if not a button or field), or returns the text property (if a button or field).

[mwieder]

No, we don't "need" to create a synonym <g>, I just think it makes better syntactic sense to use the plural if referring to a list. You don't say "put the frontscript" to get the list.

I understand the parsing problems with "set the behavior to object", and I guess it would break the BNF model if we made an exception. It just makes for awkward syntax when you're dealing with multiple objects.

[LCMark]

Ah but 'frontScript' doesn't have the same collective connotation as 'behavior' (the 'behavior' of something naturally being a collection of things as much as one thing ).

The 'set' thing isn't so much to do with parsing as consistency. As 'set' is a general command, I'd think it would be unwise to specialize it a way that goes against common convention (that is, the right-hand-side being an expression and not an object reference); but I do get your point about it being clunky.

[mwieder]

OK - I get the thing about rvalues. It's not good to special-case this.

I don't feel strongly enough about the behavior/behaviors thing to push it too far. I'd like to see the plural as a synonym and I don't see what the objection is, but I don't feel like getting into a long discussion about the cognitive aspects of singular and pluralized references at the moment.

[LCMark]

Hehe - I wasn't really objecting so much as playing devil's advocate (although I'm not a fan of the general notion of synonyms). In regards to long discussions about the cognitive aspects of singular and pluralized references, I'm not sure I'm qualified

[monte]

Hmm... is there going to be much code out there that depends the behavior returning a single object reference? I'm fairly sure I've got some.... I guess though that most of that code is only going to be in the IDE and plugins which I don't think we should be afraid to break if there's good reason.

[mwieder]

My primary suspect was PowerDebug, because I extract the object referrence from the executionContexts, but I planned ahead for this and to my amazement it works.
I do think some warning is necessary so that anyone who may be affected has a chance to modify their code before this gets rolled out, but I think the collateral damage will be minimal.