FEATURE_INHERITED_PARENTSCRIPTS

[monte]

I was going to propose 'myself' the other day but then thought better of it. It's just another way to say 'me' isn't it?

[monte]

How about 'the effective behavior of me'

Where the effective adjective ensures that the behavior returned is the script object rather than the first parent behavior.

[LCMark]

I just realised that the scriptObject could get confusing if we ever get OOP...

Can you elaborate on what you mean here?

[monte]

Well if we have objects embedded in scripts that are in objects...

I'm fairly sold on the effective behavior of me now though...

[Martin Koob]

I like Monte's suggestion of 'this behavior'. Looking at Trevor's example

Custom Control (a group) [Control 1]
'Developers Extension of Custom Control' button [Control 2] is assigned as a behavior to 'Control 1'. (A behavior implementing some additional behavior developer wants to add.)
'Actual Custom Control Behavior' button [Control 3] is assigned as a behavior to 'Control 2'. (Behavior containing actual custom control implementation.)

When the 'Actual Custom Control Behavior' script is executing 'this me' returns a reference to 'Control 3', while 'me' returns a reference to 'Control 1'. As a custom control developer I can then use the 'this me' reference to determine the card that 'Control 3' is on and reference any other controls or buttons my custom control needs that reside on that card.

Note that there is not (currently) a way to determine the existence of 'Control 2' while executing the script of 'Control 3'. This doesn't bother me as I don't have a scenario where you would need to know that.

me - would always refer to the final control in the chain.
this behavior - would always refer to the scriptobject where the term is contained in. This could be used to refer to the intermediary control (Trevor's control 2), as well as the original control.

Custom Control [Control 1]
me - returns a reference to control 1
this behaviour - returns reference to control 1 *not sure if there would be a need for this

Developers extension of Custom Control Button [Control 2]
me - returns a reference to control 1
this behaviour - returns reference to control 2

Actual Custom control behaviour [Control 3]
me - returns a reference to control 1
this behaviour - returns reference to control 3

I think adding the adjective effective confuses things. Effective means the end result after all operations are performed. So in the case of behaviours I would think that the effective behaviour is the eventual behaviour of control 1 after taking into account all the behaviours that affect it.

[FourthWorld]

FWIW, I like "scriptObject", since it's an unusual token for an unusual need, not likely to be confused with anything else. Easy to remember, easy to type.

Along these lines, for the rarer-but-not-unthinkable need to know all of the objects in an object's message path, might we consider extending this further to include:

the effective scriptObjects of <objDescriptor>

...which would return a return-delimited list of all objects in the
message path of <objDescriptor>?

[mwieder]

@Monte- the problem with "the effective behavior" is that it works the opposite way from "the effective" whatever elsewhere in xtalk.

The effective backgroundColor returns "the backgroundColor" if it's set in the current object, otherwise it works back through the object path until it can return a non-empty backgroundColor.

The analogy here would be for "the effective behavior" to return "the behavior" if there's a behavior object set for the current object, and otherwise work backwords through the groups, card, stack until a behavior can be resolved.

[mwieder]

I still think that maybe "myself" is the most xtalk-like term:

Code: Select all

put the someProperty of myself into tProp
add 1 to it
set the someProperty of myself to tProp

This retains the syntactical structure and context of "me" and unambiguously refers to the conainer of the script, whether or not the container is currently acting as the behavior of another object.

[monte]

As I pointed out on the use list with the effective working screenRect there's no inheritance involved just modification of the result. I'm not going to push it though if people don't think it's right.. I'm happy to side with the majority on one of my early suggestions 'the scriptObject'.

[LCMark]

@monte:
I agree there's precedent in using 'effective' in non-inheritence scenarios - so I don't think there would be anything necessarily wrong with 'the effective behavior of me'.

However, really we want the facility to return the object of the running script which means that 'the effective behavior of me' would be returning 'me' in the case of the behavior being empty, or in the case of a handler executing in me (and not one of its chained behaviors).

Looking at it from a consistency point of view, I wonder if this would be better posed as a local property - we have 'the target', and 'the caller' has been proposed - 'the scriptObject' would fit here but how about considering 'the behavior' again...

If we adapt the (slightly ephemeral) mental model slightly there's a generalization. At the moment we are used to seeing objects as owning a script and having behaviors... However, if we imagine an object which has a 'built-in' behavior (its script), then the idea of scripts uniformly fits into the 'behavior' idea. (After all, the script of an object defines it's behavior). This would then add weight to using 'the behavior' for the property that is currently 'this me'.

In this vein, we could even consider adding 'the object' as a synonym for me. Giving us the following list:

• the target - the object to which the current message was originally sent.
• the caller - the object which sent the message
• the behavior - the object containing the script that is currently executing
• the object - the object which is at the root of the behavior chain which is currently executing (me)

@FourthWorld:
Might I suggest 'the messagePath of <object>' - it's perhaps a bit clearer and more succinct. It would return a return-delimited list (in order - front to back) of long ids of objects containing the scripts at each step of the message path (including the object itself).

[FourthWorld]

@FourthWorld:
Might I suggest 'the messagePath of <object>' - it's perhaps a bit clearer and more succinct. It would return a return-delimited list (in order - front to back) of long ids of objects containing the scripts at each step of the message path (including the object itself).

I like it!

[trevordevore]

@runrevmark: I like it too. Ship it and end our misery

[LCMark]

Okay - it looks like 6.1.1-rc-2 is approaching stability so we probably want to ship it quite soon... However, I do feel that the 'this me' issue hasn't been entirely resolved yet. We have three options:

1. We mark 'this me' as experimental (i.e. that the syntax is not firm and we are still evaluating it) and spend a little more time pondering what the best syntax should be and finalize the syntax in the next major version.
2. We pick one of the other options presented above (the behavior, the scriptObject, this behavior, the effective behavior of me, ...) (I'm not sure any stands out as a 'preferred' option yet) and live with the consequences.
3. We keep 'this me' for the current engine, and review it in the context of the 'cleaning up syntax project' in the refactored engine which will appear later on this year.

I am leaning towards (1) (and less so (3)) at the moment - just because this is will not be an oftenly used feature, so the price of changing it in the next major version to something we all are reasonably comfortable with is quite low.

[trevordevore]

I'm fine with (1) but I thought your discussion of 'the behavior' and 'the object' made sense. I would be fine with 'the behavior'.

[LCMark]

I'm fine with (1) but I thought your discussion of 'the behavior' and 'the object' made sense. I would be fine with 'the behavior'.

Ah - I thought you were agreeing with @FourthWorld and referring to my 'the messagePath' suggestion.