LiveCode Forums.

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.

in particular, the ancestor script locals are shared amongst all uses

Ha! That would cause some head-scratching at debug time. We'd need a new category of semi-global local vars.

mwieder wrote:Ha! That would cause some head-scratching at debug time. We'd need a new category of semi-global local vars.

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.

runrevmark 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.

It would be. I just can't remember the exact use case I came across once at this late hour

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.

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???

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.

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"?

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???

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?

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"?

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. I don't think 'shared' need be an adjective of either 'global' or 'local' (since it's a storage option midway between really, rather than a modification of one of the other types) and it then fits well with the idea that there's an implicit 'variable' keyword lurking:

Yes, "shared" is a better connotation than "public" for this usage.

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?

The situation is confusing enough for developers with "me" and "the target" and "this <object>".
Can we check for IsBehavior()? Is there a reference count somewhere that identifies an object as being a behavior of some other object?

How about using the 'this' keyword?

..."this" isn't bad as a modifier, but "behavior" is already used for another context, as in "set the behavior of".

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)

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

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.