MessagePath - backScripts question
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
MessagePath - backScripts question
Hi all,
I presume it is possible to insert the script of stack <xxx> into back for any number of stacks and handlers from all of these stacks would be accessible to each other?
Is there any significant disadvantage to doing this?
many thanks
Stam
I presume it is possible to insert the script of stack <xxx> into back for any number of stacks and handlers from all of these stacks would be accessible to each other?
Is there any significant disadvantage to doing this?
many thanks
Stam
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: MessagePath - backScripts question
Hi.
Inserting a script into back places it just before the engine. If you place more than one script into back, they order themselves with the most recently inserted placed in front of any others previously inserted.
So it is just a way to manually adjust the scripts in the message path. There is nothing bad about doing that, nor how many you decide you want to put there. But know that since you are custom building your own "back" of the message path, you have to remember the order of the ones you put there.
Craig
Inserting a script into back places it just before the engine. If you place more than one script into back, they order themselves with the most recently inserted placed in front of any others previously inserted.
So it is just a way to manually adjust the scripts in the message path. There is nothing bad about doing that, nor how many you decide you want to put there. But know that since you are custom building your own "back" of the message path, you have to remember the order of the ones you put there.
Craig
Re: MessagePath - backScripts question
Thanks Craig, that is very good to know.
I had assumed that rather than an another series of hierarchical steps in the message path, this might be a 'bubble' with no internal hierarchy, clearly i was very wrong!
There will be a place for me to use this, but not as i had originally guessed - thank you.
I had assumed that rather than an another series of hierarchical steps in the message path, this might be a 'bubble' with no internal hierarchy, clearly i was very wrong!
There will be a place for me to use this, but not as i had originally guessed - thank you.
Re: MessagePath - backScripts question
@stam: I think Craig's characterization may be slightly misleading...
Whenever a message is sent to an object, the message flows through the message path - first through the front scripts, then to the object targetted by the call, then up the ownership chain, then through the backscripts - the frontscripts and backscripts are always passed through (until a matching handler is hit) regardless of the target object.
So if you have a stack called Foo with script, whose script is inserted into back:
The call to 'myOtherBackscriptCommand' is the same as `send myOtherBackscriptCommand to me` - it will still go through all frontscripts, then to the stack Foo, then through all the backscripts (and yes, this does mean it is possible to engineer things such that a backscript handler is called twice!).
The order of insertion controls the order in which scripts are checked for handlers - however, that is only really a concern if you have multiple scripts in back (or front, or anywhere) with the same name and are using pass. If all handlers have different names, then the backScripts are exactly as you suggest a 'bubble' where order does not matter.
So, for all intents and purposes, you have your 'bubble' - two backscripts can each refer to each others handlers without a problem.
Whenever a message is sent to an object, the message flows through the message path - first through the front scripts, then to the object targetted by the call, then up the ownership chain, then through the backscripts - the frontscripts and backscripts are always passed through (until a matching handler is hit) regardless of the target object.
So if you have a stack called Foo with script, whose script is inserted into back:
Code: Select all
command myBackscriptCommand
myOtherBackscriptCommand
end myBackscriptCommand
The order of insertion controls the order in which scripts are checked for handlers - however, that is only really a concern if you have multiple scripts in back (or front, or anywhere) with the same name and are using pass. If all handlers have different names, then the backScripts are exactly as you suggest a 'bubble' where order does not matter.
So, for all intents and purposes, you have your 'bubble' - two backscripts can each refer to each others handlers without a problem.
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: MessagePath - backScripts question
@LCMArk.
What did I say in my post that was misleading?
I think what Stam meant as a "bubble" was a self-contained mini message path, not part of the ordinary message path. But I never said anything, I believe, that implied such a bubble existed.
Craig
What did I say in my post that was misleading?
I think what Stam meant as a "bubble" was a self-contained mini message path, not part of the ordinary message path. But I never said anything, I believe, that implied such a bubble existed.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: MessagePath - backScripts question
Hmmm.
Was it "...since you are custom building your own "back" of the message path...?
Perhaps that should have been worded better. I certainly did not mean to imply that a separate message path was created when one inserts a script "into back", but rather that such scripts are placed "just before the engine", but in the only message path we have.
Craig
Was it "...since you are custom building your own "back" of the message path...?
Perhaps that should have been worded better. I certainly did not mean to imply that a separate message path was created when one inserts a script "into back", but rather that such scripts are placed "just before the engine", but in the only message path we have.
Craig
Re: MessagePath - backScripts question
@dunbarx: No - it was due to suggesting the order was important - which it isn't if all your handlers are named differently (order *only* matters if you are using handlers with the same name and pass).
I think what Stam was asking was whether a handler in backscript can call any handler in any other backscript - regardless of any order of insertion - which it can. i.e. (Assuming all your handlers in all your backscripts are named differently) The backscripts as a whole can be thought of as collection of handlers which can be called from anywhere, including any other backscript.
[ The reason I said 'misleading' was mainly because Stam had asked whether things worked a certain way, but after your description appeared to think that what he wanted to do wouldn't work, when it would - that's all ].
I think what Stam was asking was whether a handler in backscript can call any handler in any other backscript - regardless of any order of insertion - which it can. i.e. (Assuming all your handlers in all your backscripts are named differently) The backscripts as a whole can be thought of as collection of handlers which can be called from anywhere, including any other backscript.
[ The reason I said 'misleading' was mainly because Stam had asked whether things worked a certain way, but after your description appeared to think that what he wanted to do wouldn't work, when it would - that's all ].
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: MessagePath - backScripts question
LCMArk.
Ah, I see.
Checking the dictionary, it says:
So why mention that, unless it is to warn that one might want to be careful to order scripts with similar names? This seems insane to me on the face of it.
Craig
Ah, I see.
Checking the dictionary, it says:
This is true, i suppose, but irrelevant, since, as you say, if handlers are named differently, it does not matter where in the "pile" of backScripts a particular handler might be placed. If in a back script at all, they have equal statusObjects added to the front or back are placed at the start of the frontScripts or backScripts list: the last-inserted object gets messages first.
So why mention that, unless it is to warn that one might want to be careful to order scripts with similar names? This seems insane to me on the face of it.
Craig
Re: MessagePath - backScripts question
Thanks both, this discussion was very illuminating and while I’m not quite certain how I’ll end up implementing things yet, my take-away is that an easy way to ensure a handler is accessible to other libraries is to put its script in the backscript, caution with namespacing notwithstanding…
Thanks both! (And I hope I understood correctly!)
Stam
Thanks both! (And I hope I understood correctly!)
Stam
Last edited by stam on Tue Feb 15, 2022 1:07 am, edited 1 time in total.
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: MessagePath - backScripts question
Stam.
I bet you do indeed get it, but does "name spacing" mean handler naming?
Craig
I bet you do indeed get it, but does "name spacing" mean handler naming?
Craig
Re: MessagePath - backScripts question
avoid conflicting names... or for a fancypants clarification, wikipedia is your friend https://en.wikipedia.org/wiki/Namespace