FEATURE_INHERITED_PARENTSCRIPTS

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, LCMark

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Wed May 01, 2013 12:38 am

Hmm... I'd assumed it wouldn't really be a true mix in. Just an ordered list of behaviors on an object so the inhertance path would go:

object
behavior 1
behavior 1's behavior 1
...
behavior 1's behavior n
....
behavior n
object parent etc
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3013
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by mwieder » Wed May 01, 2013 12:48 am

...a little hard to get a picture of that from the description, but it sounds like you're putting "behavior 1" and "behavior n" at the same level. And that's how I picture multiple inheritance working (or not working). How would prioritization work there? Let's say all the behavior objects have a "version()" function in them and the main object doesn't. If you ask for the version of the main object, which one would you get?

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Wed May 01, 2013 1:18 am

Sorry... not at the same level... that's the opposite of what I was intending to say. The behaviors would be an ordered list so there really wouldnt be much difference between:

Code: Select all

set the behavior of object 1 to object 2
set the behavior of object 2 to object 3
and

Code: Select all

set the behaviors of object 1 to object 2&cr&object 3
The only difference is object 2 wouldn't always need to inherit from object 3...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1088
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Wed May 01, 2013 10:53 am

As Monte says it would just be a prioritized list so if you have the following arrangement:

Code: Select all

Object
      Behavior 1
      Behavior 2
        Behavior 3
      Behavior 4
The message order would be:

Code: Select all

    Object
    Behavior 1
    Behavior 2
    Behavior 3
    Behavior 4
As I said above, this could be a useful feature to allow 'mix-in' type functionality - particularly with before and after handlers. For example, you could have a custom tool-tip behavior, a behavior that logged actions - all kinds of things. Certainly it gives the scripter the power to tie themselves in knots if the behaviors overlap in their functionality - but then that's just a case of using the feature appropriately and designing carefully.
Last edited by LCMark on Wed May 01, 2013 11:13 am, edited 1 time in total.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Wed May 01, 2013 10:58 am

@runrevmark... each of those behaviors could have their own inheritance path of parent behaviors too... I assume you would follow the complete inheritance path for each behavior before moving to the next behavior...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1088
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Wed May 01, 2013 11:13 am

@monte: that was a formatting fail (corrected now!) - yes the inheritence chain would be followed for each behavior in turn.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Wed May 01, 2013 11:16 am

Ah... I did wonder why you had the same list twice ;-)
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3013
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by mwieder » Wed May 01, 2013 3:41 pm

Coming into this late, I can only guess at what it looked like before. :P
But the message inheritance for the mixins makes sense.

I'd also like to suggest that "the behaviors" be a synonym for "the behavior" as we move into this space, to allow for the cases of

Code: Select all

put the behaviors of control x
set the behavior of control x to
where either "behavior" or "behaviors" would use a cr-separated list.
And can we please "set the behavior to the object" rather than "to the long id of the object"?

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1088
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Wed May 01, 2013 3:53 pm

Do we need to make a synonym there? You don't say 'his behaviors were unusual', you say 'his behavior was unusual'; this seems to suggest setting the behavior of an object to a list makes as much sense as setting the behaviors of an object to a list...

In regards to:

Code: Select all

set the behavior of control x to <object>
Then, no, that isn't possible. Set is a command that takes a property and an expression - what the property is doesn't matter to it. It evaluates the expression, then calls 'setprop()' using it. When an object chunk is evaluated in expression context it either throws an error (if not a button or field), or returns the text property (if a button or field).

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3013
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by mwieder » Wed May 01, 2013 5:31 pm

No, we don't "need" to create a synonym <g>, I just think it makes better syntactic sense to use the plural if referring to a list. You don't say "put the frontscript" to get the list.

I understand the parsing problems with "set the behavior to object", and I guess it would break the BNF model if we made an exception. It just makes for awkward syntax when you're dealing with multiple objects.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1088
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Wed May 01, 2013 5:43 pm

Ah but 'frontScript' doesn't have the same collective connotation as 'behavior' (the 'behavior' of something naturally being a collection of things as much as one thing ;)).

The 'set' thing isn't so much to do with parsing as consistency. As 'set' is a general command, I'd think it would be unwise to specialize it a way that goes against common convention (that is, the right-hand-side being an expression and not an object reference); but I do get your point about it being clunky.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3013
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by mwieder » Wed May 01, 2013 5:55 pm

OK - I get the thing about rvalues. It's not good to special-case this.

I don't feel strongly enough about the behavior/behaviors thing to push it too far. I'd like to see the plural as a synonym and I don't see what the objection is, but I don't feel like getting into a long discussion about the cognitive aspects of singular and pluralized references at the moment.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1088
Joined: Thu Apr 11, 2013 11:27 am

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by LCMark » Wed May 01, 2013 6:00 pm

Hehe - I wasn't really objecting so much as playing devil's advocate (although I'm not a fan of the general notion of synonyms). In regards to long discussions about the cognitive aspects of singular and pluralized references, I'm not sure I'm qualified ;)

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1561
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by monte » Wed May 01, 2013 11:55 pm

Hmm... is there going to be much code out there that depends the behavior returning a single object reference? I'm fairly sure I've got some.... I guess though that most of that code is only going to be in the IDE and plugins which I don't think we should be afraid to break if there's good reason.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3013
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: FEATURE_INHERITED_PARENTSCRIPTS

Post by mwieder » Thu May 02, 2013 12:44 am

My primary suspect was PowerDebug, because I extract the object referrence from the executionContexts, but I planned ahead for this and to my amazement it works.
I do think some warning is necessary so that anyone who may be affected has a chance to modify their code before this gets rolled out, but I think the collateral damage will be minimal.

Post Reply

Return to “Engine Contributors”