FEATURE_INHERITED_PARENTSCRIPTS

[LCMark]

I'm not sure there's necessarily any issue overloading keywords in distinct contexts.

Indeed, I think there is potentially a fair amount of synergy in using 'the behavior' to do what we need here. We'd then end up with:

Code: Select all

  put me -- returns the object handling the message (even if currently in a behavior)
  put the target -- returns the object the message was originally sent to
  put the behavior -- returns the object to which the script containing the current handler is attached

[LCMark]

Okay - think I managed to fix the problems with the inherited behaviors implementation and so have now merged into into 'develop'. The only outstanding thing to do is implement access to the behavior object as is currently being discussed, but apart from that (hopefully) the functionality is complete (and correct!)

[mwieder]

Tests worked ok. Both "me" and "the target" are agnostic as to the original source, no matter whether they're placed in a nested behavior or in the target object. I'm able to get a reference to the behavior control by

Code: Select all

    if the number of items of line -1 of the executioncontexts is 4 then
        put "parent::context:" && item -1 of line -1 of the executioncontexts & cr after msg
    else
        put "parent::context:" && item 1 of line -1 of the executioncontexts & cr after msg
    end if

If the parser won't have a problem with "this behavior" then I guess that's ok, but I think I'd prefer "this control", as I think the generic form would be useful in other contexts as well.

[LCMark]

If the parser won't have a problem with "this behavior" then I guess that's ok, but I think I'd prefer "this control", as I think the generic form would be useful in other contexts as well.

To my mind (at the moment at least - my mind is slightly addled today) I don't think 'this control' is right at all - after all what we are talking about is a reference to the behavior that is currently executing... Although behavior scripts are (at the moment) tied to a control, they aren't control-like in any way (as used as a behavior, at least).

In terms of using 'this', then I'm also not sure that's correct (again - at the moment at least - my mind is slightly addled today). Right now 'this' is used to refer things in the current 'default' object hierarchy (this card, this stack) to fill in 'missing' parts of a chunk expression which doesn't really seem a good fit when you are talking about script execution environments.

[mwieder]

To my mind (at the moment at least - my mind is slightly addled today) I don't think 'this control' is right at all - after all what we are talking about is a reference to the behavior that is currently executing... Although behavior scripts are (at the moment) tied to a control, they aren't control-like in any way (as used as a behavior, at least).

OK, but... I thought the issue was trying to reference the behavior object in order to access its custom properties. And in that case it does indeed act like a control.

Or perhaps I'm misunderstanding why we're trying to get a reference to the behavior object. My mind is also slightly addled by the jetlag, although the caffeine is helping.

[mwieder]

I tend to think of behaviors as local backscripts that shadow the original control, so maybe there's some fertile ground for coming up with a naming analogy.

[monte]

Hmm... the behavior seems a bit confusing to me when we have behavior inheritance because it seems ambiguous which one it means.... this behavior makes more sense there. Another alternative might be some function like `the scriptObject`, however, do we have our horses and carts in the wrong order. Perhaps we just need the shared variable type and then the need to reference the object to store data in custom properties goes away???

[mwieder]

I'm fine with that. I think you're the one who brought up the desire to reference custom props in the behavior object in the first place. I kind of like the idea, but I can't think of a problem for it to solve.

[monte]

hmm... I guess there's supporting data that you could put in the properties of the behaviour rather than have copies of it in every custom control.

[LCMark]

Code: Select all

Hmm... the behavior seems a bit confusing to me when we have behavior inheritance because it seems ambiguous which one it means.... this behavior makes more sense there. Another alternative might be some function like `the scriptObject`, however, do we have our horses and carts in the wrong order. Perhaps we just need the shared variable type and then the need to reference the object to store data in custom properties goes away???

I think you may have hit the nail on the head in terms of what we are looking for here - we need a generic way to reference the object to which the currently executing script is attached. Perhaps looking at it that way might be better than focusing on its use for just behaviors. The generic term would resolve to the same object as 'me' for non-behaviors, and then the appropriate object in the behavior chain for things-acting-as-behaviors.

I think 'the scriptObject' is definitely a candidate - but it does seem a little clunky (on first inspection) and I wonder if we could come up with something succinct. Thinking a bit more widely here there's a variety of object references 'available' internally whenever a handler is executing:

• the object to which the message was sent (the target)
• the object currently executing the message whether in a behavior or not (me)
• the object that made the call (not yet defined - maybe the caller)
• the object to which the script containing the current handler is attached (not yet defined - maybe the scriptObject)

[mwieder]

Hmmm... "me" and "the target" seem to return the same value, whether in a behavior script or in the original control. I think that's proper, so I'm not suggesting changing it.

The term "this scriptObject" does seem a bit clunky, and also has problems if you elevate a button to being a behavior object... what's the context if a button is not being used as a behavior (while it's being developed) and you reference "this scriptObject"? If it still refers to the control that contains the script, then "this control" or "this object" would still do the trick. Since we're restricted to buttons for behavior objects, then even "this button" would do. But none of those really stand out for me as being a reference to the behavior object itself rather than any other control. Maybe "this behavior"? "this behaviorObject"?

[monte]

I don't really like the scriptObject either... was just throwing it out there... Perhaps we are being a bit pedantic here between this behavior and the behavior. In the context of authoring a particular behavior script then I guess it does make sense that the behavior returns a reference to that particular one. I'm not positive I like the idea that it will return something different to the behavior of me but I think I could live with that.

[LCMark]

Hmmm... "me" and "the target" seem to return the same value, whether in a behavior script or in the original control. I think that's proper, so I'm not suggesting changing it.

They are actually different - me is essentially an analog of 'self' (obj-c) or 'this' (c++) - it is the object that is executing the current handler (and just like self/this it is the descendent object if the handler is actually in a behavior); whereas 'the target' is the object to which the message was originally sent.

The missing piece is getting the object that actually owns the script the current handler is within - i.e. if it was a handler in a behavior, then it would be the behavior object and not the object using the behavior (which is me). Indeed, the generalization is something that returns the object owning the script the current handler is implemented in - i.e. like 'me' but it would change depending on whether the script was a behavior or not.

To clarify, let's say we have a field implementing a handler 'foobar', and the field has its behavior set to a button which implements a handler 'foobaz':

Code: Select all

send "foobar" to field
    the target - field
    me - field
    'the scriptObject' - field

send "foobaz" to field
    the target - field
    me - field
    'the scriptObject' - button

[mwieder]

@runrevmark- yes, I do understand that, I'm just reporting what I see for "me" and "the target" in both behavior scripts, inherited behaviors, and the original object. And in all those cases, "me" and "the target" return the same reference. I'm seeing a vanishing need for a reference to the behavior script object itself as long as there's a "shared" modifier for variables, but

<thinking the unthinkable>

what repercussions would there be if "me" in a behavior script returned the behavior script object itself?
I can see breakage of existing behaviors that reference "me", but they could be fixed by referencing "the target".
And having "me" reference the actual behavior object would be intuitive in terms of writing and reading the behavior script.

[LCMark]

I can see breakage of existing behaviors that reference "me", but they could be fixed by referencing "the target".
And having "me" reference the actual behavior object would be intuitive in terms of writing and reading the behavior script.

You couldn't really do this as 'the target' and 'me' really are different - the target only changes when you use 'send' - if you use 'call' or invoke a handler directly (with standard handler call syntax) then the target remains the same, but me changes.

The current definition of 'me' is perfectly consistent with the idea that it (conceptually) maps to 'this' or 'self', where they are always pointers to the derived object.

Another way to look at it is that behaviors were originally conceived as a way of sharing scripts - the goal being you should be able to copy the script out of an object and make it a behavior, make the control reference the behavior and its functionality would be unaffected.