Behavior scripts not limited to buttons?

[monte]

OK... so getting back to the topic... I've just sent a pull request to enable this:
https://github.com/runrev/livecode/pull/68

Tested with fields and it all seems to work as expected... I still think the side issue of what the behavior returns and why it doesn't conform to an object property is worthwhile discussing...

[LCMark]

@runrevmark will chime in and say that he still doesn't agree (yet) with widening the scope of what behaviors should be - although @monte has made the best point yet as to why it should be allowed:

FWIW... I totally understand that the behavior is just a script container but I also think there's utility in allowing any object to be that container. For example, if you decide an object script should be a behavior rather than have it's own script (say you need multiple copies) at the moment you need to cut and paste the code to a button... If we allowed any control then it's one less step... one less cognitive leap... make this group behave like that one... etc...

There is some truth here, however it would be better solved by a 'Move Script to Behavior' action (or similar) in the IDE. The point to remember is that any cognitive association that people have between the behavior script and the type of object that script is set on is wrong. There is absolutely no association.

One of the reasons buttons were chosen was that you drag them onto a card, name them and they have a name which you can see. You can have many on one card and thus making libraries of behaviors becomes easy. Yes, you could do this with other controls, but buttons are the only ones where the default state is that the name of the control is the label that you see. Thus limiting to buttons does force people into this structure to a certain degree - which didn't seem like to bad idea at the time because it works with how the engine currently resolves and manages such things and also seems like a perfectly reasonably way to organise things.

Another reason is that of cognition, again, widening the scope of what behaviors could be means that people will (more than likely) start to think that a field has to have a behavior that is also a field - even though, again, there is no association there. The behavior object is just a script container, nothing more.

Now, while at first sight, it might make sense to think that 'oh, a field should 'inherit' from a field' - if you extend this, then you get into a state where cards should 'inherit' from cards, and stacks should 'inherit' from stacks (cognitively at least). However, this doesn't really make any sense from a project organisation and editing point of view as far as I can see. Also, again, there is no inheritence (in an object sense) going on here - by using those terms and thinking of it in those ways you end up misunderstanding what behaviors actually are. (Also, remember that 6.1 will have chained behaviors which could potentially muddy cognition even further if the 'x inherits from y' meme is codified further).

Ultimately, it comes down to the fact that behaviors were designed with the best concepts available in the engine at the time. The thrust was that you'd create libraries of behavior buttons in your application on a card in a substack or separate stack, and then make the controls that use them reference them. It seemed a reasonable way to work around the fragile control references the engine has. [ Indeed, I started off with the ideal situation - behaviors were an object that was just a script, with potentially some metadata - and then worked back to a point at which it was implementable in the engine as it is ].

What was the reason behind behavior returning a rugged id?

In a loaded environment, a control is uniquely identified by the mainstack name and the id, slightly less uniquely if its a substack name and id (although the search pattern kind of helps sort that out). It is the minimal amount of information needed, and is efficient to encode in the stackfile. It was never an ideal solution, but it was the best that we came up with then.

To be honest, I don't really see a lot of value right now changing the way behaviors are referenced, nor extending them to other control types... Why? Because we have a huge re-engineering of the core of the engine around the corner that will be a base on which many of the issues with control references can be resolved in a much more elegant way. Also, it is the base upon which behaviors can finally become what they should have been - objects in their own right (thus completely eliminating any cognitive dissonance about what they are, and how the object they are relates to their function).

Is it really worth changing functionality that would potentially mean people have to update their scripts for an interim period of maybe 3-4 months, and then have to update them again? Or indeed, introducing a slight variant on a way of working which is obsoleted only a short while down the line? (I'll leave the whole, documentation, explaining, and ensuring everything still works etc. factors out for now - but they are contributory too - there is a cost to any change far beyond the cost to code it initially).

I guess my point here is that at the moment we are very much in an interim period and issues like this, 'the rugged id' and uuids have come up - and that's great - but given the huge leap the architecture is about to make it seems a little unwise to make decisions about them right now and potentially bite our noses off to spite our faces.

Now, part of the problem is that I have not yet articulated in detail what architectural changes are currently underway in the refactoring project and what this means in terms of possibilities for the future - so you guys (as yet) don't really have the same frame of reference to evaluate things as I do. For this I need a bit of time to write these things up appropriately, essentially some of the issues that have come up already are more than catered for - this includes Unicode, typing, control references and language bindings... And a lot more besides.

[monte]

What I find interesting is people struggle to come to terms with using a different object type as a behavior... I wonder if that will go away if they get their own control type? Maybe... It's been raised so many times I thought it would be fun to play with the idea...

[LCMark]

What I find interesting is people struggle to come to terms with using a different object type as a behavior... I wonder if that will go away if they get their own control type? Maybe... It's been raised so many times I thought it would be fun to play with the idea...

Indeed - it is interesting

To my mind it does suggest that behaviors (as they are) aren't all that well understood, and perhaps that people are thinking about them in slightly the wrong way. Thus I'm wary of introducing a change that might make this problem worse, rather than better.

My gut feeling is that it is because of the way they are currently expressed in the language, rather than anything else - the fact that they are tied to a control plants a seed in the mind that something more is going on than actually is.

[monte]

Possibly... however, I've got to say it does feel right coding a field object with keyDown handlers etc...

[malte]

the main problem with the as is implementation on a button as far as I can see is that the button containing the behaviour script is prone to throwing annoying errors.

A behaviour script:

Code: Select all

on mouseMove x,y
  set the hScroll of me to the hScroll of me + 1
end mouseMove

Now try to edit that script without throwing an error I'd rather prefer behaviours being faceless. But that is just me.

Another thing that always bites me...

If you have a splash screen app, that first loads the components you use and the stack containing the behaviours is opened late in the process, you need to resolve all of them (by resetting them) to make behaviours work. I wonder if the more elegant stuff @runrevmark is thinking about will take care of that.

2 cents...

[LCMark]

Now try to edit that script without throwing an error I'd rather prefer behaviours being faceless. But that is just me.

Well that's at least one argument (beyond cognitive clarity) for behaviors being an object in their own right...

If you have a splash screen app, that first loads the components you use and the stack containing the behaviours is opened late in the process, you need to resolve all of them (by resetting them) to make behaviours work. I wonder if the more elegant stuff @runrevmark is thinking about will take care of that.

I think the behavior resolution mechanism does need some thought and a little re-working (there have been suggestions of a 'resolve behaviors' command, however I'd prefer we just come up with rules which mean its unnecessary!). This should perhaps be a separate topic...

[monte]

Now try to edit that script without throwing an error I'd rather prefer behaviours being faceless. But that is just me.

Well that's at least one argument (beyond cognitive clarity) for behaviors being an object in their own right...

It's also an argument for them being the correct object type isn't it?

[monte]

I forgot to say that @runrevmark is entirely right that if the IDE had more behavior tools these issues might not exist... I have my own plugin that will take an object and move its script to a behavior for example... I also have a contextual menu on an object that allows you to edit the behavior... combined these things mean I never even see the button and couldn't care less what object it is...

[FourthWorld]

I forgot to say that @runrevmark is entirely right that if the IDE had more behavior tools these issues might not exist... I have my own plugin that will take an object and move it's script to a behavior for example... I also have a contextual menu on an object that allows you to edit the behavior... combined these things mean I never even see the button and couldn't care less what object it is...

Like this?:
http://fourthworldlabs.com/rev/behaviortool.png

[monte]

Something along those lines... The whole thing is a bit like DropTools but with a focus on behavior development workflows rather than just use. My behaviors are managed in a central repository and only included in the app when it's built. I have a manager ui for it:

https://www.dropbox.com/s/3gc2a936mpybl ... 3%20AM.png

The Add button will move a selected object to the repository using it as a template and it's script as a behavior. If the object doesn't have a script then it gets a boilerplate template...

And any object that has a behavior gets the edt behavior script contextual menu:

https://www.dropbox.com/s/34tlydmtn758c ... 4%20AM.png

[FourthWorld]

And any object that has a behavior gets the edt behavior script contextual menu:

https://www.dropbox.com/s/34tlydmtn758c ... 4%20AM.png

Nice. We definitely need that in the IDE.

[mwieder]

Agreed.

But it would still be nice to subclass behavior from like objects.
I have fields that inherit behavior from buttons, and that just hurts my head.

[dunbarx]

Is it inconceivable that behavior scripts might be associated with a new type of specialized "custom property"? These also can be both ubiquitous and numerous, live at a high level in the hierarchy, and intrinsically are disassociated from ANY object at all, spot on as per runRevmark.

set the customBehavior of fld "yourField" to the XYZBehavior of this stack

It seems like a behavior script naturally belongs high up in the message hierarchy, at stack or backscript level. But of course there are limited number of available objects that high up, whereas one can have as many buttons as needed, as cogently pointed out.

This new environment for behaviors would thus have all the advantages of being attached to an object, with none of the bad and spurious associations mentioned, except for the in-your-face naming that comes with new button creation.

Craig Newman

[monte]

It could be a faceless object like an audioClip... still... it will take a long time to deprecate and finally remove it being a button if we did that (we have a history of leaving things in for backwards compatibility) so we would end up with two abstract concepts rather than one...

One point I wouldn't mind making is a behavior being just a script is an opportunity to use a text file like we've never had before... My suggestion would be to use either a button or a text file with the standalone builder offering to bring the text files in as buttons for password protection...