@JLG I thought with "breaktpoint" you could debug SOS behaviors On Tue, Jan 23, 2018 at 1:21 PM, Geoff Canyon via use-livecode < use-livecode@lists.runrev.com> wrote:
> On Tue, Jan 23, 2018 at 9:42 AM, Mark Waddingham via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > On 2018-01-23 17:21, Geoff Canyon via use-livecode wrote: > > > >> This actually raises another point (and I'm sure this is a discussion > >> that > >> happened without me several years ago, but as long as we're here) is > there > >> a reason to use "this me" which seems terribly awkward, over "the > behavior > >> of me" which is to my ear far more straightforward (it didn't require > any > >> additional code or syntax) if a bit more verbose? > >> > > > > There's a longish thread on the engine forum about this... > > > > The 'behavior of me' works fine as long as you aren't using a chained > > behavior - in the latter case, it would only give you the behavior object > > directly attached to 'me' (i.e. the object the behavior's are acting on). > > > > Yeah, agreed, in this circumstance "the behavior of me" would be lacking. > > > > > > The need to actually get the object a behavior's script resides in is > > really quite a rare operation (the only reason I think it is useful at > all > > in the context of script-only stacks being used for behaviors is for > > resolving paths to resources relative to the behavior script file) so in > > the end I plumped for something simple to add which wasn't going to cause > > any difficulties in implementation or potential ambiguities - its > > strangeness helps reinforce the fact 'are you sure you need to do this' > as > > well :) > > > > Class variables are a fairly defined thing in the OO world, and this seems > equivalent to those. > > > > > > In actual fact, I wonder whether it is really needed at all for behaviors > > expressed as script only stacks - you can use 'the filename of stack > <name > > of behavior>' - which is more verbose but means you can avoid 'this me'. > > (Given that if you change the name of a behavior, any references to it > > break, you are forced to choose your behavior names wisely - hence why we > > use reverse-dns notation in the IDE). > > > > Pondering slightly, if we codify the notion of a script object (i.e. > > something which is just a script), then perhaps we could have: > > > > - this object (me): the object currently executing > > > > - this script (this me): the script currently executing > > > > Perhaps something to consider in the future (I've not spent any time > > considering whether 'this script' might have a more useful connotation!). > > > > I'd propose the following: > >>> > >>> script <script-name> with behavior <behavior-name> > >>> > >>> Where <behavior-name> is resolved as a stack reference. > >>> > >>> > >> Sure, that sounds perfect. > >> > > > > I did a patch for this whilst having coffee this morning: > > > > https://github.com/livecode/livecode/pull/6290 > > > > It garnered some discussion internally - mainly whether the idea of a > > 'loadStack' message would be better. I think it was decided that > > 'loadStack' (i.e. a message sent after a stack is loaded, but before > opened > > - something which happens whenever you reference a stack via a chunk > > without a go/open verb) was an orthogonal thing (and a fair bit more > > difficult to implement!). > > > > Still needs some tests and generally checking around the idea - but as it > > stands at the moment it seems like a reasonable addition. > > > > Woot! > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > 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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode