FEATURE_INHERITED_PARENTSCRIPTS
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: FEATURE_INHERITED_PARENTSCRIPTS
I took a look at the INHERITED_PARENTSCRIPTS code last week and noticed a couple of flaws (in particular, the ancestor script locals are shared amongst all uses, rather than being per inheritence chain). That being said, I think I've managed to fix those issues so am hoping to push them into a feature branch with the inherited parentscripts enabled soon.
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
Ha! That would cause some head-scratching at debug time. We'd need a new category of semi-global local vars.in particular, the ancestor script locals are shared amongst all uses
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
It's funny you should mention that - I do remover wondering at the time we added behaviours whether a 'shared local' at the script level might be useful... I.e. vars that are shared between all instances of a behavior.mwieder wrote:Ha! That would cause some head-scratching at debug time. We'd need a new category of semi-global local vars.
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
It would be. I just can't remember the exact use case I came across once at this late hourrunrevmark wrote:I do remover wondering at the time we added behaviours whether a 'shared local' at the script level might be useful... I.e. vars that are shared between all instances of a 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
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
I wonder how much confusion it would cause to have script locals in behavior scripts private by default (the current situation) and have a new keyword specifier of "public" for the shared local vars...
I'm not wild about it because it's too much like the morass of global variables, but I can see where it would come in handy and where the alternatives would be tricky to deal with. So forcing the user to explicitly enter a public specification would help ensure that they have to think about the repercussions.
The confusion would be because the default for handlers is "public" rather than "private", while the opposite would be true for variables in behavior scripts. But I think requiring the "private" keyword at this point would break existing functionality too much.
Code: Select all
local sLocalVar -- new instance for each behavior instance
public local sSharedVar -- value is shared and modifiable for each behavior instance
The confusion would be because the default for handlers is "public" rather than "private", while the opposite would be true for variables in behavior scripts. But I think requiring the "private" keyword at this point would break existing functionality too much.
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
Hmm... I would expect a public script local to be only available down the inheritance path rather than across instances. It's also no longer really a local if that happens. I don't think it's really necessary given it's safer to use a function and command to get and set a local in that case.
I'm struggling to come up with a use case for a shared local between instances of a behavior. I guess the problem is if you did need one the only current solution would be to use a global... but then again if you did need one then perhaps what you really need is a companion library or backscript for your behavior???
I'm struggling to come up with a use case for a shared local between instances of a behavior. I guess the problem is if you did need one the only current solution would be to use a global... but then again if you did need one then perhaps what you really need is a companion library or backscript for your behavior???
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
A couple of examples to consider where a variable that is shared across all instances of a behavior would be useful.
When the control initializes for the first time, it might query the system for certain OS values that should be used when rendering the control (e.g scrollbar width on Windows). No need to do this for every instance of the custom control if there is a shared variable.
Or perhaps you have custom controls that are themed. At the root of all of your custom controls (buttons, fields, etc.) you have a behavior that controls the theme. Being able to share the theme variable across all instances would be ideal. There would be a setter inherited by all controls. Setting it would update the theme for all controls as you would update the shared variable and each control would be notified that it needed to refresh itself.
I would much prefer a shared variable to having to use a global variable. I like my controls to be nice and protected from the dangerous outside world.
When the control initializes for the first time, it might query the system for certain OS values that should be used when rendering the control (e.g scrollbar width on Windows). No need to do this for every instance of the custom control if there is a shared variable.
Or perhaps you have custom controls that are themed. At the root of all of your custom controls (buttons, fields, etc.) you have a behavior that controls the theme. Being able to share the theme variable across all instances would be ideal. There would be a setter inherited by all controls. Setting it would update the theme for all controls as you would update the shared variable and each control would be notified that it needed to refresh itself.
I would much prefer a shared variable to having to use a global variable. I like my controls to be nice and protected from the dangerous outside world.
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
Hmm... There is another option other than global variables in setting the custom properties of the behavior of me. Although, that's not going to be robust when the inherited behaviors rolls in and even worse if we got mix-in. Maybe we need to be able to reference the behavior object from the behavior script in a robust way???
OK, I'm sold. I still don't like the name "public local" for this which doesn't seem to describe what it is. Perhaps "shared"?
OK, I'm sold. I still don't like the name "public local" for this which doesn't seem to describe what it is. Perhaps "shared"?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: FEATURE_INHERITED_PARENTSCRIPTS
Hehe - yup - there needs to be a reference like 'me' which resolves to the behavior script's object. The question is... What should it be called?Hmm... There is another option other than global variables in setting the custom properties of the behavior of me. Although, that's not going to be robust when the inherited behaviors rolls in and even worse if we got mix-in. Maybe we need to be able to reference the behavior object from the behavior script in a robust way???
I dislike the use of 'public' and 'private' too - they have too many connotations from other language which aren't really valid in this case. I always thought 'shared' would work.OK, I'm sold. I still don't like the name "public local" for this which doesn't seem to describe what it is. Perhaps "shared"?
Code: Select all
global gVar -- one copy, shared amongst all scripts
shared hVar -- one copy, shared amongst all uses of the behavior
local sVar -- one copy per instance of behavior
Code: Select all
global variable gVar
shared variable hVar
local variable sVar
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
Yes, "shared" is a better connotation than "public" for this usage.
Can we check for IsBehavior()? Is there a reference count somewhere that identifies an object as being a behavior of some other object?
The situation is confusing enough for developers with "me" and "the target" and "this <object>".Hehe - yup - there needs to be a reference like 'me' which resolves to the behavior script's object. The question is... What should it be called?
Can we check for IsBehavior()? Is there a reference count somewhere that identifies an object as being a behavior of some other object?
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
How about using the 'this' keyword?
Code: Select all
put the long id of this behavior into theLongID
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
..."this" isn't bad as a modifier, but "behavior" is already used for another context, as in "set the behavior of".
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
But isn't that exactly what we are trying to get a reference to? not the behavior of me but this behavior (the object that's script is being executed)
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
Yes, I'm just saying that
a) I don't think the parser will allow us to do this and
b) I don't like repurposing an existing function/property name
in other words, "behavior" is not a container, it's a property of an object. With that in mind, "this behavior" might syntactically be "the behavior of me" but not "the object to which this script is associated". If we try to elevate "behavior" to a full-fledged container then I think there are other syntactic difficulties to deal with... for instance, is "the number of behaviors of <object>"
a) the number of behavior objects contained in a card or group
b) the number of nested parent objects of <object>
c) if mix-ins are allowed, the number of mixed-in behaviors
a) I don't think the parser will allow us to do this and
b) I don't like repurposing an existing function/property name
in other words, "behavior" is not a container, it's a property of an object. With that in mind, "this behavior" might syntactically be "the behavior of me" but not "the object to which this script is associated". If we try to elevate "behavior" to a full-fledged container then I think there are other syntactic difficulties to deal with... for instance, is "the number of behaviors of <object>"
a) the number of behavior objects contained in a card or group
b) the number of nested parent objects of <object>
c) if mix-ins are allowed, the number of mixed-in behaviors
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
OK, another suggestion could be adding `this control` to the engine. If it isn't a behavior script executing then this control would = me otherwise it would refer to the behavior object being executed.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/