controlIDs|Names of group
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: controlIDs|Names of group
Cool. Originally I was thinking controlIDs but childControlIDs seemed to be clearer... also the number of controls and the number of lines of the controlIDs should return the same number. I guess it would be clear if I implemented controlIDs and childControlIDs so there was an obvious difference. Hmm... I don't know why I didn't think of implementing this for cards too...
If it were implemented for cards should sharedGroups be included? I usually iterate over them separately to ensure sharedGroups are only parsed once.
If it were implemented for cards should sharedGroups be included? I usually iterate over them separately to ensure sharedGroups are only parsed once.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: controlIDs|Names of group
The 'the childControlIds of group ...' seems like a worthy addition to me - as does 'the childControlIds of card ...' (hint hint ).
In terms of naming then it is important to remember that the current action of 'control ...' when searching is to recurse through all controls - whether in groups or not. Thus distinguishing between 'the controlIds' and 'the childControlIds' is important - in particular, the 'child' variants don't recurse (in the modern world, of course, this seems slightly backward - however the current semantics of control searching isn't something that can be realistically changed at this time as it is what everybody is used to).
Of course, ideally at some point we'll have something like:
However, adding that is significantly more involved than the properties...
P.S. 'the selectGroupedControls of group ...' is intended as something to purely affect selection - it shouldn't have any effect on script.
In terms of naming then it is important to remember that the current action of 'control ...' when searching is to recurse through all controls - whether in groups or not. Thus distinguishing between 'the controlIds' and 'the childControlIds' is important - in particular, the 'child' variants don't recurse (in the modern world, of course, this seems slightly backward - however the current semantics of control searching isn't something that can be realistically changed at this time as it is what everybody is used to).
Of course, ideally at some point we'll have something like:
Code: Select all
repeat for each [ child ] control [ id ] <var> in <object> [ where <expr> ]
...
end repeat
P.S. 'the selectGroupedControls of group ...' is intended as something to purely affect selection - it shouldn't have any effect on script.
Re: controlIDs|Names of group
Great runrevmark... now that I know you are keen I'll implement the rest of it. Yes, I was thinking childControlIDs of cards also controlIDs and controlNames of both group and card. Should be able to have most of the code in common for controlIDs and childControlIDs ... just turn on the recursive bit when it's controlIDs... it's a pity there isn't a container class between control and group/card so we could implement this kind of thing in one place...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: controlIDs|Names of group
Ahh - yes - the lack of a 'container' abstraction has always irked me slightly also... However, pragmatically, cards are a different sort of container from groups - cards only hold a list of references to objects (MCObjptr's), where as groups hold a list of objects (MCObject's). This distinction is to handle the ability to have shared groups amongst cards.
Re: controlIDs|Names of group
OK... I'd seen MCObjptr but hadn't looked into it...So... I guess the code might not be as similar as I thought
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: controlIDs|Names of group
I hadn't looked into that either. I take it, then, that an MCObjPtr isn't a handle to an MCObject?
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: controlIDs|Names of group
It seems to be a list to put controls in where you can give them a different parent... While an MCControl can only have one parent multiple cards could have the same MCControl in the MCObjPtr with the different cards as the parent. Kind of makes me wonder if we could have shared controls that aren't in groups but not sure if we ant to bother going there...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: controlIDs|Names of group
I've had a look at card and I noticed groupIDs which jogged my memory that there is a precedent for returning just the childIDs in a property like this. Makes me wonder if it shouldn't just be controlIDs rather than childControlIDs but I'm happy either way and also happy to implement both.
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: controlIDs|Names of group
I realize the "child" nomenclature was my idea in the first place, but it seems to work the opposite from the way I'd intuitively expect it to work, i.e., "the childControls" of a group should, I think, return all the controls in the group and "the controls" of the group should return the first-level children. Given that the current situation isn't going to change without breaking most every stack out there, I'm good with either "controlIDs" or "childControlIDs". The "controlIDs" seems more in line with the "groupIDs", so I guess that makes more sense. I really want something that says "hey... these are only your immediate family", but I can't think of a good natural language way to name that.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: controlIDs|Names of group
I've actually implemented both controlIDs and childControlIDs although I only really want childControlIDs it was another 5 minutes work to do them both... I'm happy to reverse the names so it's the childControlIDs that recurses through the tree.
Now the big question is whether sharedGroups should be returned in the childControlIDs of a card... I'm hoping I can get away with not including them although the current implementation does include them. That will save me from having to check if a group is shared before parsing it because shared groups need to be handled separately so they aren't parsed multiple times.
Now the big question is whether sharedGroups should be returned in the childControlIDs of a card... I'm hoping I can get away with not including them although the current implementation does include them. That will save me from having to check if a group is shared before parsing it because shared groups need to be handled separately so they aren't parsed multiple times.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: controlIDs|Names of group
I think it needs to be 'childControl*' for only the immediate children... The reason here is that people currently understand 'control' as recursing, thus 'child control' would restrict to just immediate children (not an ideal situation, granted, but one we have inherited - for now).
In regards to shared groups - then, yes, they should be included since from that context they are immediate children (and controls). You can easily check if a group is shared though - if it has 'sharedBehavior' true, then it could be on more than one card, and if it is the cardIds of it (which is pending integration ) will have more than one line. Alternatively, you can use the 'sharedGroupIds' of a card then filter whilst processing the childControlIds list.
In regards to shared groups - then, yes, they should be included since from that context they are immediate children (and controls). You can easily check if a group is shared though - if it has 'sharedBehavior' true, then it could be on more than one card, and if it is the cardIds of it (which is pending integration ) will have more than one line. Alternatively, you can use the 'sharedGroupIds' of a card then filter whilst processing the childControlIds list.
Re: controlIDs|Names of group
Right... that's what I've done then. Pushed the card change and added controlIDs|Names too this morning.I think it needs to be 'childControl*' for only the immediate children... The reason here is that people currently understand 'control' as recursing, thus 'child control' would restrict to just immediate children (not an ideal situation, granted, but one we have inherited - for now).
Hmm... well the sharedBehavior can currently be true on a nested group which is why I sent that other pull request. Even if that's fixed we can no longer rely on it unless when the stackfile loads nested groups get their sharedBehavior set correctly...In regards to shared groups - then, yes, they should be included since from that context they are immediate children (and controls). You can easily check if a group is shared though - if it has 'sharedBehavior' true, then it could be on more than one card, and if it is the cardIds of it (which is pending integration ) will have more than one line. Alternatively, you can use the 'sharedGroupIds' of a card then filter whilst processing the childControlIds list.
The sharedGroupIDs of the card is reliable though... are you sure I can't interest you in unsharedChildControls of card
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: controlIDs|Names of group
Ah - indeed - I just found the comment on MCStack::checksharedgroups() about how it never unsets it... I'll have to try and remember why I didn't make it more draconian.Hmm... well the sharedBehavior can currently be true on a nested group which is why I sent that other pull request. Even if that's fixed we can no longer rely on it unless when the stackfile loads nested groups get their sharedBehavior set correctly...
Re: controlIDs|Names of group
Reviewed the code for MCStack::checksharedgroups()... It only iterates over top-level groups and ensures that any that should have the 'shared' bit set do, in fact, have the shared bit set. Its purpose is to ensure that any (top-level) group that is placed on more than one card does have this bit set. It should be a simple matter to enforce nested groups not having this bit set - I'll file a bug about it and see what we can do.
Re: controlIDs|Names of group
Ack - looks like I managed to thoroughly confuse myself with this one (mainly by not reading more closely!)... For some reason I though 'controlIds' existed already for some object (card?) hence my vehemence that the immediate children search should be childControlIds. Sorry about that :S
So, just to reiterate the argument (so I can clarify it in my own mind as much as anything else!)...
At the moment doing 'control id x of ...' will cause a fully recursive search of the card (or group) for said control. Thus when we add 'repeat for each control id ...', it should probably do the same otherwise you have a difference in interpretation of what 'control id x' means in two different contexts. Now my thinking on this was (at some point) we could add a 'child' adjective to control chunks so: 'child control id x of' ... would be like 'repeat for each child control id x of ...' and only search immediate children. This resulted in my jumping on the 'childControlIds' band-wagon as it gives the following 'nice' equivalence:
is the same as:
Which is the same equivalence as you have with 'repeat for each key x of ' and 'repeat for each line x in the keys of'.
This is all well and good - except that 'controlIds' doesn't yet exist, and 'groupIds' (the example mwieder gives) only returns the top-level groups of a card i.e. only immediate children. So by introducing 'childControlIds' there is a non-uniformity between that and 'groupIds'.
So it seems we have two options:
1) Have 'childControlIds' be immediate children only : giving consistency with the idea of 'control' chunks being all descendents (and, in the future, the same as 'child control' chunk) but break consistency with 'groupIds of card'.
2) Forget about 'childControlIds' and make controlIds only return immediate children : breaking consistency with the idea of 'control' chunks being all descendents, but keeping consistency with 'groupIds' of card'.
One option to mitigate this perhaps is to (in the future) consider a context-local property that controls how far the search goes (e.g. the searchDescendents). If this is true, the 'control' would be its current behavior, if false it would be the child-only behavior. We could then have adjectives 'child' and 'descendent' to override it. This could even work with properties 'the groupIds' / 'the controlIds' would use the state of the flag; 'the childControlIds' would override.
[ Incidentally, I am thinking quite far ahead here as when we get the new syntax parser, property names will be able to be things like - the [ child | descendent ] control ids - thus we won't descend too far into multi-word-camel-case-property-name-hell ].
[ Another incidentally, I think the whole 'search descendent control' behavior actually stems from the idea of backgrounds which is inherited from HyperCard. i.e. The idea that the controls in a background placed on a card are in some sense 'unified' with those on the card and thus you shouldn't have to reference them as children of the background. As groups were/are an extension of this it was probably never considered that when being used as a non-background they should (perhaps) not have this behavior. ]
So, just to reiterate the argument (so I can clarify it in my own mind as much as anything else!)...
At the moment doing 'control id x of ...' will cause a fully recursive search of the card (or group) for said control. Thus when we add 'repeat for each control id ...', it should probably do the same otherwise you have a difference in interpretation of what 'control id x' means in two different contexts. Now my thinking on this was (at some point) we could add a 'child' adjective to control chunks so: 'child control id x of' ... would be like 'repeat for each child control id x of ...' and only search immediate children. This resulted in my jumping on the 'childControlIds' band-wagon as it gives the following 'nice' equivalence:
Code: Select all
repeat for each [ child ] control id x of tObject
... do stuff with x ...
end repeat
Code: Select all
repeat for each line x in the [child]controlIds of tObject
... do stuff with x ...
end repeat
This is all well and good - except that 'controlIds' doesn't yet exist, and 'groupIds' (the example mwieder gives) only returns the top-level groups of a card i.e. only immediate children. So by introducing 'childControlIds' there is a non-uniformity between that and 'groupIds'.
So it seems we have two options:
1) Have 'childControlIds' be immediate children only : giving consistency with the idea of 'control' chunks being all descendents (and, in the future, the same as 'child control' chunk) but break consistency with 'groupIds of card'.
2) Forget about 'childControlIds' and make controlIds only return immediate children : breaking consistency with the idea of 'control' chunks being all descendents, but keeping consistency with 'groupIds' of card'.
One option to mitigate this perhaps is to (in the future) consider a context-local property that controls how far the search goes (e.g. the searchDescendents). If this is true, the 'control' would be its current behavior, if false it would be the child-only behavior. We could then have adjectives 'child' and 'descendent' to override it. This could even work with properties 'the groupIds' / 'the controlIds' would use the state of the flag; 'the childControlIds' would override.
[ Incidentally, I am thinking quite far ahead here as when we get the new syntax parser, property names will be able to be things like - the [ child | descendent ] control ids - thus we won't descend too far into multi-word-camel-case-property-name-hell ].
[ Another incidentally, I think the whole 'search descendent control' behavior actually stems from the idea of backgrounds which is inherited from HyperCard. i.e. The idea that the controls in a background placed on a card are in some sense 'unified' with those on the card and thus you shouldn't have to reference them as children of the background. As groups were/are an extension of this it was probably never considered that when being used as a non-background they should (perhaps) not have this behavior. ]