Re: Why Chained Behaviors May Be A Bad Idea
mwieder wrote: Hopefully that's a typo and not a circular reference. So A | BC | D Is perfectly reasonable. B has access to A, C has access to A, D has access to C and A. But not B. To use a textbook example, if A=shape, B=circle, C=triangle, and D=right triangle you wouldn't expect (or want) a right triangle to inherit anything from circles, but any changes to triangle should be accessible from right triangles. You might want all circles to be blue and all triangles to be red. Those would be handlers in the B and C scripts. You could then have all right triangles be black (in the D script), and that wouldn't affect other types of triangles. BR: yes that was a typo: thanks for this "textbook example" very helpful… gives me the courage to try using it… as it could solve a number of challenges where re-use of code *should* be the best practice but exactly how to accomplish that without polluting a global API (backscript) with all kinds of non-global, extraneous handlers/functions (and mysterious since you lose context)… --one just needs to adopt a smart naming convention so that in the PB, you know what is going on by look at the behavior/scripts file names… Thanks for your patient responses BR ___ 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
Re: Why Chained Behaviors May Be A Bad Idea
Sannyasin Brahmanathaswami wrote > but the example was > > Parent X (a behavior for) > Child Y and Child X, > where Child X was also a behavior for > Child A Hopefully that's a typo and not a circular reference. So A | BC | D Is perfectly reasonable. B has access to A, C has access to A, D has access to C and A. But not B. To use a textbook example, if A=shape, B=circle, C=triangle, and D=right triangle you wouldn't expect (or want) a right triangle to inherit anything from circles, but any changes to triangle should be accessible from right triangles. You might want all circles to be blue and all triangles to be red. Those would be handlers in the B and C scripts. You could then have all right triangles be black (in the D script), and that wouldn't affect other types of triangles. - -- Mark Wieder ahsoftw...@gmail.com -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Why-Chained-Behaviors-May-Be-A-Bad-Idea-tp4708303p4708354.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ 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
Re: Why Chained Behaviors May Be A Bad Idea
Mark Weider wrote: That is indeed classical inheritance. Multiple inheritance is properly not allowed in LiveCode and would look like this Behavior_button A Behavior Button B Behavior Button C # has both button A and button B assigned as behaviors # not chained, but in parallel BR: right, you can't do that… but the example was Parent X (a behavior for) Child Y and Child X, where Child X was also a behavior for Child A Mark:Inheritance (behaviors) in LiveCode *allow* you to use functionality in parent objects, but don't force you to do so. And you can override the parent behaviors by placing handlers of the same name in the child object. BR: Ahha! that's an important point/option. Thanks for listening… I learned something there. ___ 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
Re: Why Chained Behaviors May Be A Bad Idea
Sannyasin Brahmanathaswami wrote > Theoretically I could have (I will declare these as objects, but of course > now we can also use livecodescript text only stacks) > > Behavior_button A > > Behavior Buttons B and C > # both have behavior A assigned > > Button D ># with button C assigned as behavior > > How is this not "inheritance"? That is indeed classical inheritance. Multiple inheritance is properly not allowed in LiveCode and would look like this Behavior_button A Behavior Button B Behavior Button C # has both button A and button B assigned as behaviors # not chained, but in parallel Inheritance (behaviors) in LiveCode *allow* you to use functionality in parent objects, but don't force you to do so. And you can override the parent behaviors by placing handlers of the same name in the child object. -- Mark Wieder ahsoftw...@gmail.com - -- Mark Wieder ahsoftw...@gmail.com -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Why-Chained-Behaviors-May-Be-A-Bad-Idea-tp4708303p4708332.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ 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
Re: Why Chained Behaviors May Be A Bad Idea
Mark Wieder" wrote: Well, most of the article rants about multiple inheritance, which is indeed a bad idea. But of course you know that's different from chained behaviors, so no worries there. BR: actually I don't know how that is different, probably I just don't understand it well enough, if I did, perhaps I would not be afraid of it. Backscripts are "easy" but I am seeing instances where better encapsulation will help avoid issues and if some functions truly are not needed globally then a strong case could be made to use behaviors for specific event sequences. In our current app, we are using independent modules(stacks) that use global functions in the loader stack and a core API backscript (and a few others) But some of these modules are so unique that requirements for Module Y will never appear as a requirement for Modules A, B, C (separate stacks) Theoretically I could have (I will declare these as objects, but of course now we can also use livecodescript text only stacks) Behavior_button A Behavior Buttons B and C # both have behavior A assigned Button D # with button C assigned as behavior How is this not "inheritance"? ___ 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
Re: Why Chained Behaviors May Be A Bad Idea
On 09/11/2016 07:22 PM, Sannyasin Brahmanathaswami wrote: A bit OT, but this was interesting to me.. https://www.quora.com/Is-inheritance-bad-practice-in-OOP "kinda" validated my gut feeling about nesting behaviors Well, most of the article rants about multiple inheritance, which is indeed a bad idea. But of course you know that's different from chained behaviors, so no worries there. I had to laugh about a self-proclaimed "Perl expert" arguing about OOP, but he does have one great quote: "If none of the AOP stuff that I wrote made any sense, let me paraphrase: AOP was a an experiment that accidentally made its way into the wild and when found, should be beaten to death viciously with hammers." -- Mark Wieder ahsoftw...@gmail.com ___ 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
Why Chained Behaviors May Be A Bad Idea
A bit OT, but this was interesting to me.. https://www.quora.com/Is-inheritance-bad-practice-in-OOP "kinda" validated my gut feeling about nesting behaviors BR ___ 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
