Two very useful OOP-style features

[fgr33n]

I'd like to suggest two OOP features that would greatly enhance the ability to create functionality, and organize and reuse code in LC. (I cringe every time I have to copy and paste identical code for lack of an easier way to reuse it.)

First, would be the addition of independent scripting objects, or scripts that can be created and instanced independently of a control, stack or card. In other words, an independent scripting window and scripts that are fully featured and functional objects in and of themselves, able to contain custom properties, and execute their own handlers. These scripting objects could be instanced in a global variable for a custom-class-like functionality, instance other objects , passing parameters and receiving data returned from them, affect the properties of other objects; or they could be instanced in a more localized, time-limited context for a more efficient implementation of all kinds of functionality.

Closely related to independent scripting objects would be the expansion of the current shared behaviors feature to include the attaching and execution of multiple behaviors. This would involve expanding the current single-behavior name field to a list that could contain any number of behaviors to be executed in sequence. While sharing the behavior of a single button is useful, having a library of independent, reusable, behavior scripts that could be attached to any button or control would be HUGE.

A forum search reveals that OOP has appeared as a feature request before, but I thought it may be a good time to revisit it, as the roadmap currently lists only two queued projects (physics and Win8).

I know many long-time LC'ers may never have used OOP in other languages, and have learned to do things in a procedural way, so they don't miss it. However, once having OPP capability, it is really hard to go back, as it is so much easier to create functionality, and organize and reuse code. This makes all aspects of an app's lifecycle easier to manage.

I'm curious how many LC developers would like to see OOP added to LC?

[mwieder]

check out behaviors.

[FourthWorld]

And note that behaviors can now be chained, effectively giving us subclassing.

[dunbarx]

The OP said this:

This would involve expanding the current single-behavior name field to a list that could contain any number of behaviors to be executed in sequence. While sharing the behavior of a single button is useful, having a library of independent, reusable, behavior scripts that could be attached to any button or control would be HUGE.

I read this as he is familiar with LC behaviors, and their ability to chain. I am only writing to find out more about the functionality he is hoping for. For example, a list of behavior scripts in the inspector as opposed to the single line field there currently. I am not sure how this would work.

I was tempted to suggest the usual, libraries, backScripts and plug-ins, but somehow think that there is a higher layer of OOP that I am not getting here. After all, we have had stacks in use since HC 2.0.

Craig Newman

[jacque]

Maybe the OP is unfamiliar with stacks in use?

[fgr33n]

but somehow think that there is a higher layer of OOP that I am not getting here.

Sorry it to so long to respond and clarify. I've been under a hard deadline for the past month or so.

If I'm understanding chained behaviors (and admittedly I'm still pretty new to LiveCode, so may be missing something) you can assign the behavior property of a button to another button that is in turn already serving as a behavior for some other button or control. Don't get me wrong. Having chained behaviors is better than single behaviors, but since this is a feature request forum... How much better to be able to assign multiple behaviors directly to a control and skipping the whole chaining-thing.

I've attached an example pic of the behavior windows from Adobe Director. There are six behaviors assigned to this control (and probably more as the widow scrolls). They execute in the order they are listed in the window. Flash, Flex and Dreamweaver all have a similar behavior windows where you can assign multiple behaviors.

I have no idea how hard this may be for the LC team, but moving LC more toward a full OOP implementation, rather than "OOP-like", seems like a great idea to me.

[FourthWorld]

If not chained, how is behavior precedence resolved if more than on behavior has the same handler?

[dunbarx]

Hi.

Is it possible that this following scenario is what you are thinking of? Make two buttons on a new card. In one button, named "xyz", place this in its script:

Code: Select all

on mouseUp
   put random(999)
end mouseUp

on mouseDown
   put any char of "asdfghjklpoiuytyrewq"
end mouseDown

Set the behavior of the other button to the long name of btn "xyz". Now when you click on that button, you see a random letter followed by a random number. Two messages are sent to the behavior script, which contains two unique handlers, but both are separate and unique, with their own functionality.

I am not sure I understand how "multiple behaviors" could be implemented, or even what that means. LC is message and event driven, and if there is going to be multiple anything, it ought to follow the scenario above, with multiple handlers for multiple messages. Can you give an example (pseudoExample?) of what you mean?

Craig

Craig

[fgr33n]

If not chained, how is behavior precedence resolved if more than on behavior has the same handler?

Hi Richard, In the Adobe-OOP implementation (Director/Lingo/Javascript, Flash/ActionScript, Flex/ActionScript Dreamweaver/Javascript) each behavior has its own event handlers, and they execute in the order the behaviors are placed in the list. When the mouse is pressed, the "on mouseUp" runs in the first behavior if it has one, then the second, and so on to the end of the list.

The same is true for any of the other events. i.e. "mouseUp, mouseWithin, and ect. Each time an event is passed it is run in each behavior where there is a handler for the event, starting at the top of the list and going down.

In the Director window pictured above, the behaviors can be re-ordered with the small up and down arrows at the upper right of the window. The other Adobe dev tools work the same.

Is it possible that this following scenario is what you are thinking of?

Hi Craig, if I understand what you are saying you have described LC behaviors as they now are which provides an "OOP-like" functionality. I'm talking about taking another step in the OOP direction for even more encapsulation, flexibility and ease of use.

Can you give an example (pseudoExample?) of what you mean?

Ok, here goes....

Button 1 (on a "Code" card)

Custom property added in property inspector: cDownBlend

Code: Select all

// DECRIPTION: sets the blend level on mouseDown or touch to make a button appear to get lighter
local tBlend

on mouseDown
    put the blend of me into tBlend
    set the blendLevel of me to cDownBlend of me
end mouseDown

on mouseUp
    set the blendLevel of me to tBlend
end mouseUp

Button 2 on Code card
Custom property added in property inspector: cCursor

Code: Select all

// DECRIPTION: changes cursor on rollover

on mouseEnter
    set the cursor to cCursor of me
end mouseEnter

on mouseLeave
    set the cursor to arrow
end mouseLeave

Button 3 on Code card
Custom property added in property inspector: cDestination

Code: Select all

// DECRIPTION: goes to new card on click or touch

on mouseUp
    go to card cDestination of me
end mouseUp

Button 4 is a UI element on a visible card

Has custom properties: cDownblend = 50, cCursor = (number for hand or something), cDestination = (name of card to go to)

In the property inspector's new behavior list
Behaviors:
button 1 of card "Code"
button 2 of card "Code"
button 3 of card "Code"

When rolling over the button the cursor would change
When the mouse is down it would change to a new blend level.

on mouseUp it would change back to the original blend (first mouseUp handler runs)
and then go to the new card. (second mouseUp handler runs)

The above is a pseudo scenario with multiple behaviors using the current IDE features and the addition of a behavior list, rather than a single field. I recognize that this simple scenario could be done with chained behaviors. However if you start trying to chain 7 or 8 of them like in the Director example above it becomes very tedious and confusing. Moreover, if you need the chaining hierarchy to change at runtime, I assume you would have to reassign all those chained relationships with code, correct? (makes my head hurt just thinking about it).

However, as independent scripting objects are central to OOP, it would be much more flexible and powerful if the behaviors could be defined as an independent scripting object s, independent of buttons/cards. This was the first part of the feature request. Independent script objects also sets the stage for true OOP scripting-- parent scripts/class objects, child scripts and etc.

I have no idea how much work this would be for the LC team. I heard Jacque say recently in a webinar that there are several million lines of code in the LC IDE (Yikes!). Still this is a feature request forum, and I'd really love to see more OOP features implemented in LC, as it is so much easier in the long run.

For me, independent script objects and multiple behaviors would be two of the most useful OOP features.

Imagine having an entire library of behaviors in a library panel that could be easily assigned to controls-- maybe by dragging and dropping? Depending on what you need to accomplish, you could add a lot of them or just a few-- or create a new one if you need something you haven't already done. When you drop one on a control it would be "assigned" in the order it was dropped. A window could open asking for the custom property values. How cool would that be?

[dunbarx]

I see. The behavior list sort of works "backward" than what we already have, in that it "points" to handlers in child objects as opposed to multiple child objects "pointing" to a script in the behavior button. Do I have that right?

That is how it is different than simply loading a single behavior script with multiple messages.The same message can be in more than one child script. And chained behaviors, since they can "pass" messages, sort of do what you are proposing, just in a linear, bound up schema.

I also think that virtual objects are very cool. Never mind that only buttons can be the current behavior objects. I complained in a thread long ago that stacks were more logical a place for this sort of thing, being farther up (sorry, Jacque) the hierarchy. And why not have any object be so empowered?

Craig

[FourthWorld]

In the Adobe-OOP implementation (Director/Lingo/Javascript, Flash/ActionScript, Flex/ActionScript Dreamweaver/Javascript) each behavior has its own event handlers, and they execute in the order the behaviors are placed in the list. When the mouse is pressed, the "on mouseUp" runs in the first behavior if it has one, then the second, and so on to the end of the list.

If the developer has control over the order in which that overloading happens, then what they're offering is very similar to LiveCode's chaining, just implemented with different mechanics and nomenclature.

In LiveCode we have one additional benefit, the option of overloading like that, and also overriding if needed. To overload we explicitly pass the message, and if not passed the message can stop with any handler we choose.

This allows us to have an instance that handles one message uniquely from others using the same behavior, while still getting the benefit of everything else the behavior provides.

And with chaining, the order in which messages are handled is very explicit, starting with the target object, then its behavior, then any behavior attached to that, etc.

Imagine having an entire library of behaviors in a library panel that could be easily assigned to controls-- maybe by dragging and dropping? Depending on what you need to accomplish, you could add a lot of them or just a few-- or create a new one if you need something you haven't already done. When you drop one on a control it would be "assigned" in the order it was dropped. A window could open asking for the custom property values. How cool would that be?

Nice to have in the IDE, but in the meantime very accomplishable as a plugin made by anyone in the community.

I tend to use only one or sometimes two levels, and I set them once and never think about them again, so if I had to make this it would take me a long time before I was sufficiently motivated to finish it.

But we have rich and flexible drag-and-drop support, and the underlying behavior mechanics are robustly in place today. Anyone sufficiently motivated could probably knock that out in a day's work.

[fgr33n]

The behavior list sort of works "backward" than what we already have, in that it "points" to handlers in child objects as opposed to multiple child objects "pointing" to a script in the behavior button. Do I have that right?

Hi Craig, I think that is exactly it. In the chained behaviors, you have child objects several layers deep, as one instances the other until you get to a button that doesn't have a behavior attached (or issue a manual over-ride, as Richard mentioned). In the other scenario (IMHO the more flexible and powerful one), a single parent can instance any number of child scripts that execute in sequence, but are totally independent of each other except for a common parent.

I also think that virtual objects are very cool....And why not have any object be so empowered?

I heartily agree

then what they're offering is very similar to LiveCode's chaining, just implemented with different mechanics and nomenclature.

Hi Richard, Agreed, IMHO what is missing in LC, is an easier way to reuse the behaviors, independently of each other, as having them chained amounts to a hard-coded hierarchy that has to be over-ridden unless you want to reuse them all.

very accomplishable as a plugin made by anyone in the community....Anyone sufficiently motivated could probably knock that out in a day's work.

I know you are talking about experienced users, but as for me, I can only wish... Unfortunately, I'm still in the "scratching my head", "WTH" phase more often than not.

Still, in spite of that, I'm really liking working with LC so far, as so much tedious or complicated functionality is either really easy or totally automatic in LC. Very cool.

[FourthWorld]

In the chained behaviors, you have child objects several layers deep, as one instances the other until you get to a button that doesn't have a behavior attached (or issue a manual over-ride, as Richard mentioned). In the other scenario (IMHO the more flexible and powerful one), a single parent can instance any number of child scripts that execute in sequence, but are totally independent of each other except for a common parent.

That description seems apt for LiveCode's behaviors as well.

I know you are talking about experienced users, but as for me, I can only wish... Unfortunately, I'm still in the "scratching my head", "WTH" phase more often than not.

Everyone is a beginner once. Maybe you'll get to it later one, or maybe someone else will make one in the meantime. Maybe I'll get time to make it myself, though with my current schedule the other two options seem more likely.

Still, in spite of that, I'm really liking working with LC so far, as so much tedious or complicated functionality is either really easy or totally automatic in LC. Very cool.[/quote]
Nice to see you're having fun. Being productive is also important, but I think fun is even more important, as it ultimately yields the highest productivity.