FEATURE_INHERITED_PARENTSCRIPTS
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: FEATURE_INHERITED_PARENTSCRIPTS
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?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: FEATURE_INHERITED_PARENTSCRIPTS
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.
Where the effective adjective ensures that the behavior returned is the script object rather than the first parent behavior.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: FEATURE_INHERITED_PARENTSCRIPTS
Can you elaborate on what you mean here?I just realised that the scriptObject could get confusing if we ever get OOP...
Re: FEATURE_INHERITED_PARENTSCRIPTS
Well if we have objects embedded in scripts that are in objects...
I'm fairly sold on the effective behavior of me now though...
I'm fairly sold on the effective behavior of me now though...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 256
- Joined: Sun May 27, 2007 8:19 pm
Re: FEATURE_INHERITED_PARENTSCRIPTS
I like Monte's suggestion of 'this behavior'. Looking at Trevor's example
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.
me - would always refer to the final control in the chain.trevordevore wrote: 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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 9823
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
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>?
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>?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
@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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
I still think that maybe "myself" is the most xtalk-like term:
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.
Code: Select all
put the someProperty of myself into tProp
add 1 to it
set the someProperty of myself to tProp
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: FEATURE_INHERITED_PARENTSCRIPTS
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'.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: FEATURE_INHERITED_PARENTSCRIPTS
@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:
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 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)
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).
-
- VIP Livecode Opensource Backer
- Posts: 9823
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
I like it!runrevmark wrote:@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).
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
@runrevmark: I like it too. Ship it and end our misery
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: FEATURE_INHERITED_PARENTSCRIPTS
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:
- 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.
- 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.
- 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.
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
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'.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: FEATURE_INHERITED_PARENTSCRIPTS
Ah - I thought you were agreeing with @FourthWorld and referring to my 'the messagePath' suggestion.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'.