Behaviors and the message path

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Behaviors and the message path

Tim Bleiler
I’m curious about what appears to me to be a confusing aspect of the implementation of behaviors. In short, behaviors have characteristics of an isolated, local extension of the message path AND characteristics of a concatenation of the parent control’s script. I’m raising the issue for two reasons: 1) to clarify how to explain behaviors to someone new to Livecode or just learning about the feature and 2) to question if all the features of behaviors are intentional or if some might be accidents of implementation and therefore may be eliminated in the future.

I’ve used behaviors since they were first introduced and it’s worked well for me to think of them as an extension of the message path from the parent control. However, I recently discovered that a command in a behavior script can directly call a handler in the parent script. Furthermore, if the same handler name is present in the behavior script and the parent script, the parent script handler is the one that runs. This capability is consistent with conceptualizing the behavior script as a concatenation with the parent script and contradicts the idea that behaviors are an extension of the message path.

However, script level variables in a behavior are accessible only in the object script in which they are declared, consistent with the idea of an extended message path. Finally, If a handler with the same name exists in the parent script and a behavior script, it’s possible to execute the handler in the behavior either after the parent version runs or instead of the parent version by treating the behavior script as an independent step in the message path and using control structures like “pass”, “send” and “dispatch”. There may be more of the these types of inconsistencies but that seems more than enough to provoke some discussion on this list. I realize that any problems with these features of behaviors can easily be avoided by common sense design but some discussion seems warranted for the reasons I cited above. Anybody want to weigh in on this?

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Behaviors and the message path

Ralph DiMola
> Tim Bleiler, Ph.D. wrote
>if the same handler name is present in the behavior script and the parent script, the parent script handler is >the one that runs.

Wow! This is good to know. This could be very handy overriding a behavior handler for a specific control. As you said, there seems to be a message path conundrum here. I'm interested what Mark might have to say on this.


Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf Of Bleiler, Timothy
Sent: Thursday, December 08, 2016 3:24 PM
To: How to use LiveCode
Subject: Behaviors and the message path

I’m curious about what appears to me to be a confusing aspect of the implementation of behaviors. In short, behaviors have characteristics of an isolated, local extension of the message path AND characteristics of a concatenation of the parent control’s script. I’m raising the issue for two reasons: 1) to clarify how to explain behaviors to someone new to Livecode or just learning about the feature and 2) to question if all the features of behaviors are intentional or if some might be accidents of implementation and therefore may be eliminated in the future.

I’ve used behaviors since they were first introduced and it’s worked well for me to think of them as an extension of the message path from the parent control. However, I recently discovered that a command in a behavior script can directly call a handler in the parent script. Furthermore, if the same handler name is present in the behavior script and the parent script, the parent script handler is the one that runs. This capability is consistent with conceptualizing the behavior script as a concatenation with the parent script and contradicts the idea that behaviors are an extension of the message path.

However, script level variables in a behavior are accessible only in the object script in which they are declared, consistent with the idea of an extended message path. Finally, If a handler with the same name exists in the parent script and a behavior script, it’s possible to execute the handler in the behavior either after the parent version runs or instead of the parent version by treating the behavior script as an independent step in the message path and using control structures like “pass”, “send” and “dispatch”. There may be more of the these types of inconsistencies but that seems more than enough to provoke some discussion on this list. I realize that any problems with these features of behaviors can easily be avoided by common sense design but some discussion seems warranted for the reasons I cited above. Anybody want to weigh in on this?

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Behaviors and the message path

mwieder
(Different Mark here, but...)

Yes, that's by design and explicitly to allow for overriding.
It's *very* useful, for example, for setting up default behavior in a behavior script and then selectively overriding that in some, but not all, the objects that use that behavior script.

The issue of script-local variables only being available in the behavior script is also by design, and is consistent with the way script-local variables work in any script. It also enforces the scope of encapsulated data in the objects in the message path.

I don't see these as anomalies or inconsistencies, but as features that help implement proper object-oriented behavior. Tim- what "problems" do you see with the way this is implemented? Am I missing something?
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Tim Bleiler
> On Dec 8, 2016, at 5:09 PM, mwieder <[hidden email]> wrote:
>
> I don't see these as anomalies or inconsistencies, but as features that help
> implement proper object-oriented behavior. Tim- what "problems" do you see
> with the way this is implemented? Am I missing something?


Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my post. I agree, there are terrific benefits with the current implementation of the behavior feature. My main concern was insuring that what I observed was intended. If everything I described is by design, then the “inconsistencies” I noted are in my conceptual model of the language (extended object message path vs concatenation of scripts). Is there a better model that accounts for how the engine implements behaviors than an unpredictable combination of the two I’ve identified? An oversimplified understanding of how the engine processes scripts can get even experienced developers into trouble. The dictionary entry on "behavior" only hints at the full power of the feature and it might be difficult to expand it without invoking an accurate model of the engine’s rule set for behaviors.

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Mike Kerner
I think I need an example, because I'm not understanding the problem that
you're having with the current....behavior

On Thu, Dec 8, 2016 at 7:40 PM, Bleiler, Timothy <[hidden email]>
wrote:

> > On Dec 8, 2016, at 5:09 PM, mwieder <[hidden email]> wrote:
> >
> > I don't see these as anomalies or inconsistencies, but as features that
> help
> > implement proper object-oriented behavior. Tim- what "problems" do you
> see
> > with the way this is implemented? Am I missing something?
>
>
> Thanks Mark. I probably shouldn’t have used the word “problems” anywhere
> in my post. I agree, there are terrific benefits with the current
> implementation of the behavior feature. My main concern was insuring that
> what I observed was intended. If everything I described is by design, then
> the “inconsistencies” I noted are in my conceptual model of the language
> (extended object message path vs concatenation of scripts). Is there a
> better model that accounts for how the engine implements behaviors than an
> unpredictable combination of the two I’ve identified? An oversimplified
> understanding of how the engine processes scripts can get even experienced
> developers into trouble. The dictionary entry on "behavior" only hints at
> the full power of the feature and it might be difficult to expand it
> without invoking an accurate model of the engine’s rule set for behaviors.
>
> Tim Bleiler, Ph.D.
> Instructional Designer, HSIT
> University at Buffalo
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

mwieder
In reply to this post by Tim Bleiler
On 12/08/2016 04:40 PM, Bleiler, Timothy wrote:

> Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my post. I agree, there are terrific benefits with the current implementation of the behavior feature. My main concern was insuring that what I observed was intended. If everything I described is by design, then the “inconsistencies” I noted are in my conceptual model of the language (extended object message path vs concatenation of scripts). Is there a better model that accounts for how the engine implements behaviors than an unpredictable combination of the two I’ve identified? An oversimplified understanding of how the engine processes scripts can get even experienced developers into trouble. The dictionary entry on "behavior" only hints at the full power of the feature and it might be difficult to expand it without invoking an accurate model of the engine’s rule set for behaviors.

I think the best explanation of the message path is still Richard
Gaskin's chart and web page. Although I have to give props to Dar Scott
for his message primer as well.

I tend to think of behavior scripts (and I know there are other
viewpoints on this, so ymmv) as private backscripts fitting into the
message path right behind the objects that use them. And in that sense
behavior scripts have the same functionality as other library scripts:

behavior handlers extend the functionality of an object or a group of
similar objects

behaviors can be chained: for me this makes them more useful than
substacks, since you can't have substacks of substacks, but behaviors
allow me to have a library with compartmentalized functionality, i.e., a
math library with a special section for imaginary or complex numbers.

behavior handlers can be overridden: a handler in the library script is
in the message path unless a handler of the same name is earlier in the
message path

--
  Mark Wieder
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Tim Bleiler
On Dec 8, 2016, at 10:31 PM, Mark Wieder <[hidden email]<mailto:[hidden email]>> wrote:
I think the best explanation of the message path is still Richard Gaskin's chart and web page. Although I have to give props to Dar Scott for his message primer as well.

I tend to think of behavior scripts (and I know there are other viewpoints on this, so ymmv) as private backscripts fitting into the message path right behind the objects that use them. And in that sense behavior scripts have the same functionality as other library scripts:

behavior handlers extend the functionality of an object or a group of similar objects

behaviors can be chained: for me this makes them more useful than substacks, since you can't have substacks of substacks, but behaviors allow me to have a library with compartmentalized functionality, i.e., a math library with a special section for imaginary or complex numbers.

behavior handlers can be overridden: a handler in the library script is in the message path unless a handler of the same name is earlier in the message path

Thanks again, Mark. Your conceptualization matches how I thought about behaviors until recently. I may not have accurately communicated exactly what I’ve seen, so I’ll take Mike Kerner’s advice and provide a couple of examples. Just to be clear - I don’t have a problem with behaviors, I don’t think there’s anything wrong with the current implementation of behaviors, and I’m not advocating for any changes. In fact, I think it’s pretty clever. I just wanted to make sure that this is the intended design and if it is, to highlight the potential power and complexity of behaviors that can easily be missed.

Example 1

Script of Button A
on mouseUp
   TestScript
end mouseUp

Command ScriptInA1
   Answer "you are in Button A"
end ScriptInA1

Script 2
command TestScript
   ScriptInA1
end TestScript

Given the script of button A and that script 2 is the script of the card that owns button A, then a mouseUp on Button A will result in a “can’t find handler error” when line 2 of script 2 is reached in the card. This is consistent with the traditional Livecode control based message path. Alternatively, if the behavior of Button A is set to a button with script 2, then the engine finds the script in button A and there is no error. This is consistent with the concept that script 2 is concatenated onto the end of the script of Button A. It is inconsistent with the traditional message path.


Example 2

Script of Button A
on mouseUp
   TestScript
end mouseUp

Command ASharedHandlerName
   Answer "you are in Button A"
   # pass ASharedHandlerName
end ASharedHandlerName

Script 3
command TestScript
   ASharedHandlerName
end TestScript

Command ASharedHandlerName
   Answer "you are in Script 3"
end ASharedHandlerName

Given the script of button A and that script 3 is the script of the card that owns button A, then a mouseUp on Button A will result in an answer dialog with “You are in Script 3” as the prompt. This is consistent with the traditional Livecode control based message path. Alternatively, if the behavior of Button A is set to a button with script 3 and you think that behaviors are a private message path as Mark described, you would expect that you’d still get an answer dialog with “You are in Script 3” as the prompt just like when script 3 was the card script; but you’d be wrong. Instead you get an answer dialog with the “you are in Button A” prompt, consistent with the idea that script 3 is concatenated onto the end of the script of button A rather than being the next step in the message path. Making things even more interesting - leaving script 3 as a behavior of Button A, if you uncomment the “pass” control structure in the script of button A, then a mouseUp on Button A will result in “ASharedHandlerName” being executed from Button A and then “ASharedHandlerName” executed in the behavior script in Script 3. This is a combination of the traditional message path and a concatenation of Script 3 with the script of Button A.

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Mark Waddingham-2
In reply to this post by Tim Bleiler
On 2016-12-08 21:23, Bleiler, Timothy wrote:
> I’m curious about what appears to me to be a confusing aspect of the
> implementation of behaviors. In short, behaviors have characteristics
> of an isolated, local extension of the message path AND
> characteristics of a concatenation of the parent control’s script. I’m
> raising the issue for two reasons: 1) to clarify how to explain
> behaviors to someone new to Livecode or just learning about the
> feature and 2) to question if all the features of behaviors are
> intentional or if some might be accidents of implementation and
> therefore may be eliminated in the future.

The design of behaviors was to allow sharing of code amongst controls.
Indeed, the premise was that, given any control A, the following steps
would cause no change in functionality of A:

   1) create button B
   2) set the script of button B to the script of control A
   3) set the script of control A to empty
   4) set the behavior of control A to the long id of button B

In order for this to be the case, two things have to be true:

   1) Behaviors must keep a 'private' copy of their script locals for
each control using that behavior

   2) 'me' must always resolve to the control using the behavior, even
when in the behavior script

The key thing here is that when you call a handler from a script, unless
it is bound to a private handler in the same script, the request will
pass through the message path targeting 'me' - so first frontScripts
will trigger, then me, then the owner of me etc. Rule (2) preserves this
semantic for behaviors and, indeed, codifies the fact that behaviors
aren't really objects - they are script extensions (for want of a better
term).

The reason you see friction between what happens in the behavior chain,
and what happens in the ownership chain simply comes down to the fact
that when considering the ownership chain you are dealing with multiple
distinct objects and thus there is more than one object which is being
targetted by messages. In contrast, when you are considering the
behavior chain there is only ever a single real object - the control
using the chain - thus there is only one thing that can be the target of
message sends.

Hope this helps,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Tim Bleiler

On Dec 9, 2016, at 12:56 PM, Mark Waddingham <[hidden email]<mailto:[hidden email]>> wrote:

Rule (2) preserves this semantic for behaviors and, indeed, codifies the fact that behaviors aren't really objects - they are script extensions (for want of a better term).

Thank you Mark, your explanation is very helpful. I’m reminded again how much I appreciate your excellent stewardship of the language.

I still have one question though. Given the part of your answer I quoted above, why does the “pass” control structure trigger handlers along the behavior chain rather than skipping over them and going to the next object in the ownership chain?



Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

mwieder
Tim-

I think it's wrong to consider behavior scripts as concatenated onto the end of a script. If you rather think of the behavior script as a library or backscript, then the message path becomes a little clearer. In your example 2, the message "you are in Script 3" appears because that instance of ASharedHandlerName is in the same scope as TestScript, so it gets priority. If you then assign the behavior, you still have the same result.

What happens when you uncomment the pass command is that control then passed out of the Button A object into the next item down the message path, which will be the behavior object. You should also have (untested because lazy) the same result without assigning the behavior: you will get "you are in Button A" followed by a "pass" statement that eventually ends up at the card script and triggers "you are in Script 3".
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

mwieder
...and I want to echo your appreciation of Mr. Waddingham's stewardship of the xtalk legacy. I have argued (and will continue to do so) with him about fine points of interpretation and future direction of the language, but I always appreciate his constant conservative approach to making changes and his overview of how modifications might affect the entire ecosystem.
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

J. Landman Gay
On 12/9/16 1:49 PM, mwieder wrote:
> ...and I want to echo your appreciation of Mr. Waddingham's stewardship of
> the xtalk legacy. I have argued (and will continue to do so) with him about
> fine points of interpretation and future direction of the language, but I
> always appreciate his constant conservative approach to making changes and
> his overview of how modifications might affect the entire ecosystem.

Amen. I know that sounds like a "me too" but it deserves repetition.
He's a marvel.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Tim Bleiler
In reply to this post by mwieder

> On Dec 9, 2016, at 2:44 PM, mwieder <[hidden email]> wrote:
>
> I think it's wrong to consider behavior scripts as concatenated onto the end
> of a script. If you rather think of the behavior script as a library or
> backscript, then the message path becomes a little clearer.


Thinking of behaviors as a library/backscript or concatenated onto the end of the owner script both end up missing some important characteristics of behaviors. Mark Waddingham in his reply used a different term, which in my head can encompass the full range. Mark said, “... behaviors aren't really objects - they are script extensions (for want of a better term).”
 

> In your example 2, the message "you are in Script 3" appears because that instance of
> ASharedHandlerName is in the same scope as TestScript, so it gets priority.
> If you then assign the behavior, you still have the same result.

Maybe I didn’t explain what I’m actually doing correctly or we’re just doing something different, but after I assign the behavior I do NOT get the same result. I get a result that I think is consistent with Mark Waddingham’s explanation that the engine treats the “first” object in the behavior chain as the only “real" object and so begins processing any message within the behavior chain at the object that is returned as “Me” in any behavior scripts.


> What happens when you uncomment the pass command is that control then passed
> out of the Button A object into the next item down the message path, which
> will be the behavior object. You should also have (untested because lazy)
> the same result without assigning the behavior: you will get "you are in
> Button A" followed by a "pass" statement that eventually ends up at the card
> script and triggers "you are in Script 3”.

I agree with you on this one and it doesn’t seem to fit with my understanding of Mark Waddingham’s explanation so I posted another question about this specifically.


Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Behaviors and the message path

Ralph DiMola
In reply to this post by J. Landman Gay
"Me Too"...
Also, thanks to Tim for putting all these combinations in the lab and
reporting the results back to the community. I learned something valuable!

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]

-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf
Of J. Landman Gay
Sent: Friday, December 09, 2016 3:22 PM
To: How to use LiveCode
Subject: Re: Behaviors and the message path

On 12/9/16 1:49 PM, mwieder wrote:
> ...and I want to echo your appreciation of Mr. Waddingham's
> stewardship of the xtalk legacy. I have argued (and will continue to
> do so) with him about fine points of interpretation and future
> direction of the language, but I always appreciate his constant
> conservative approach to making changes and his overview of how
modifications might affect the entire ecosystem.

Amen. I know that sounds like a "me too" but it deserves repetition.
He's a marvel.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

mwieder
In reply to this post by Tim Bleiler
Tim Bleiler wrote
Maybe I didn’t explain what I’m actually doing correctly or we’re just doing something different, but after I assign the behavior I do NOT get the same result.
Er...yes, you're right. That's what happens when I try to multitask and type without thinking.
The other project I was multitasking on didn't work that well either. :=P

Go by what I said earlier about overriding, ignore the bit about scoping.

But at any rate, I believe conflating "extending" a script with "concatenation" is the wrong way to think about behaviors.
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

J. Landman Gay
On 12/9/16 4:47 PM, mwieder wrote:
> But at any rate, I believe conflating "extending" a script with
> "concatenation" is the wrong way to think about behaviors.

I think of them as private backscripts, available only the object to
which they are attached. If the behavior doesn't catch a messages, the
message continues on to the next object after the backscript's owner.

One thing that surprised me recently was a behavior attached to a shared
background field. A mouseUp message activated when I didn't expect it
to. I finally realized that because the behavior was attached to a
background field, it was being triggered after the card controls. I set
the field's backgroundBehavior to false (but left the shared property
true) and the unexpected responses stopped because the field was now a
card object.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

mwieder
On 12/09/2016 03:15 PM, J. Landman Gay wrote:
> On 12/9/16 4:47 PM, mwieder wrote:
>> But at any rate, I believe conflating "extending" a script with
>> "concatenation" is the wrong way to think about behaviors.
>
> I think of them as private backscripts, available only the object to
> which they are attached.

So... Either I'm not crazy or I've got company.

--
  Mark Wieder
  [hidden email]



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

J. Landman Gay
Actually I got the idea from you.  But so far it seems to hold.

Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



On December 9, 2016 8:27:18 PM Mark Wieder <[hidden email]> wrote:

> On 12/09/2016 03:15 PM, J. Landman Gay wrote:
>> On 12/9/16 4:47 PM, mwieder wrote:
>>> But at any rate, I believe conflating "extending" a script with
>>> "concatenation" is the wrong way to think about behaviors.
>>
>> I think of them as private backscripts, available only the object to
>> which they are attached.
>
> So... Either I'm not crazy or I've got company.
>
> --
>   Mark Wieder
>   [hidden email]
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Mark Waddingham-2
In reply to this post by Tim Bleiler
On 2016-12-09 19:44, Bleiler, Timothy wrote:
> I still have one question though. Given the part of your answer I
> quoted above, why does the “pass” control structure trigger handlers
> along the behavior chain rather than skipping over them and going to
> the next object in the ownership chain?

Because it is helpful for it to do so.

Either 'pass' could act as you say and skip the entire behavior chain;
or it could do as it currently does and pass to the next script in the
list of things which might want to process the message.

Given the utility of pass in the exisiting message path, it seemed
sensible that it should do the 'similar' thing in the behavior chain. As
currently implemented, it means that you can get a whole list of things
to 'do something' on a particular event; should each one pass (just as
you can with the 'normal' message path).

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Behaviors and the message path

Tim Bleiler
Thanks for taking the time to explain this Mark. After I thought about it for awhile I expected that this would be your answer and again I’m very pleased with how you’ve implemented the behavior feature.


Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

> On Dec 12, 2016, at 4:38 AM, Mark Waddingham <[hidden email]> wrote:
>
> On 2016-12-09 19:44, Bleiler, Timothy wrote:
>> I still have one question though. Given the part of your answer I
>> quoted above, why does the “pass” control structure trigger handlers
>> along the behavior chain rather than skipping over them and going to
>> the next object in the ownership chain?
>
> Because it is helpful for it to do so.
>
> Either 'pass' could act as you say and skip the entire behavior chain; or it could do as it currently does and pass to the next script in the list of things which might want to process the message.
>
> Given the utility of pass in the exisiting message path, it seemed sensible that it should do the 'similar' thing in the behavior chain. As currently implemented, it means that you can get a whole list of things to 'do something' on a particular event; should each one pass (just as you can with the 'normal' message path).
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12