FEATURE_INHERITED_PARENTSCRIPTS
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: FEATURE_INHERITED_PARENTSCRIPTS
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
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/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
...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?
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: FEATURE_INHERITED_PARENTSCRIPTS
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:
and
The only difference is object 2 wouldn't always need to inherit from object 3...
Code: Select all
set the behavior of object 1 to object 2
set the behavior of object 2 to object 3
Code: Select all
set the behaviors of object 1 to object 2&cr&object 3
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: FEATURE_INHERITED_PARENTSCRIPTS
As Monte says it would just be a prioritized list so if you have the following arrangement:
The message order would be:
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.
Code: Select all
Object
Behavior 1
Behavior 2
Behavior 3
Behavior 4
Code: Select all
Object
Behavior 1
Behavior 2
Behavior 3
Behavior 4
Last edited by LCMark on Wed May 01, 2013 11:13 am, edited 1 time in total.
Re: FEATURE_INHERITED_PARENTSCRIPTS
@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/
Re: FEATURE_INHERITED_PARENTSCRIPTS
@monte: that was a formatting fail (corrected now!) - yes the inheritence chain would be followed for each behavior in turn.
Re: FEATURE_INHERITED_PARENTSCRIPTS
Ah... I did wonder why you had the same list twice
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
Coming into this late, I can only guess at what it looked like before.
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
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"?
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
And can we please "set the behavior to the object" rather than "to the long id of the object"?
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: FEATURE_INHERITED_PARENTSCRIPTS
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:
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).
In regards to:
Code: Select all
set the behavior of control x to <object>
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: FEATURE_INHERITED_PARENTSCRIPTS
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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: FEATURE_INHERITED_PARENTSCRIPTS
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
Re: FEATURE_INHERITED_PARENTSCRIPTS
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/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: FEATURE_INHERITED_PARENTSCRIPTS
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev