Chained Behaviors

[Monte Goulding]

On 13/07/2013, at 5:47 AM, Peter Haworth <pete at lcsql.com> wrote:

> OK, good example, thanks.  I have to ask, though, why not have the unique
> mouseUp handlers in the sprite scripts and a behavior script for the common
> mouseDown handler?

Because that would mean replication and more maintenance if there's a lot of sprites with the same handler.

Here's an idea... why don't we put all our code into big switch statements in the mainstack script... that sounds like fun ;-)

I've got another use case. The mApp framework is a behavior script for the mainstack of the app. It has a small amount of code that's only in there for development support... standalone building, drag and drop of images onto the app etc. This code really shouldn't be in the built app. With chained behaviors I can put it in a support behavior that doesn't get's copied to the stackfile during the build.

Most of my behaviors are based on the same boilerplate template so there's lots of common code. If I could move most of that to a parent behavior I'd be very happy to do so because any fixes would be applied to all...

Like Richard I've been waiting for this for years. One of my biggest gripes about LiveCode is that it's sometimes hard to avoid replicating the same code all over the place. If you need to change something then you need to change it everywhere. It's easy to introduce bugs there because you miss one or two spots where you didn't change the code.

Whenever there's a significant new feature added to LiveCode there's always a certain about of "what's in it for me" going on on this list. People want the things they need to be higher priority. Well the good news on this one is it was all implemented when behaviors were first introduced and was just #ifdefed out. So it was a money for jam investment as far as RunRev was concerned. It was just a case of out of sight out of mind until a few of us spotted the tantalisingly named FEATURE_INHERITED_PARENTSCRIPTS ... 

There seems to be a certain element that believe that Mark Waddingham is the only thing holding back a tide of open source contributors that want to turn LiveCode into a low level language and ruin your platform. It's just plain untrue and I think it's a very harmful attitude to have. Why not stop and think what might motivate someone to put their spare time into working on the engine? If anything the open source move gives everyone a chance to become involved in feature development discussions and implementations to ensure all the Xtalk ducks are in a row.

Cheers

--
Monte Goulding

M E R Goulding - software development services
mergExt - There's an external for that!