FEATURE_INHERITED_PARENTSCRIPTS

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, LCMark

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Thu Aug 08, 2013 5:40 am

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/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Thu Aug 08, 2013 6:02 am

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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1033
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Thu Aug 08, 2013 10:05 am

I just realised that the scriptObject could get confusing if we ever get OOP...
Can you elaborate on what you mean here?

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Thu Aug 08, 2013 10:20 am

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

I'm fairly sold on the effective behavior of me now though...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Martin Koob
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 237
Joined: Sun May 27, 2007 8:19 pm

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by Martin Koob » Thu Aug 08, 2013 3:04 pm

I like Monte's suggestion of 'this behavior'. Looking at Trevor's example
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.
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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6836
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by FourthWorld » Thu Aug 08, 2013 3:12 pm

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>?
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2826
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by mwieder » Thu Aug 08, 2013 10:02 pm

@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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2826
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by mwieder » Thu Aug 08, 2013 10:06 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Thu Aug 08, 2013 10:17 pm

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/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1033
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Fri Aug 09, 2013 11:29 am

@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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6836
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by FourthWorld » Fri Aug 09, 2013 2:42 pm

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).
I like it!
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 960
Joined: Sat Apr 08, 2006 3:06 pm
Location: Overland Park, Kansas
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by trevordevore » Fri Aug 09, 2013 2:56 pm

@runrevmark: I like it too. Ship it and end our misery :-)
Trevor DeVore
ScreenSteps - http://www.screensteps.com

Levure Application Framework: https://github.com/trevordevore/levure
LiveCode Resources for Developers: http://livecode.bluemangolearning.com

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1033
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Thu Aug 15, 2013 11:47 am

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 960
Joined: Sat Apr 08, 2006 3:06 pm
Location: Overland Park, Kansas
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by trevordevore » Thu Aug 15, 2013 12:44 pm

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 - http://www.screensteps.com

Levure Application Framework: https://github.com/trevordevore/levure
LiveCode Resources for Developers: http://livecode.bluemangolearning.com

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1033
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Thu Aug 15, 2013 12:58 pm

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.

Post Reply

Return to “Engine Contributors”