controlIDs|Names of group

[mwieder]

multi-word-camel-case-property-name-hell

Don't want to get into too-many-dashes-hell either
Or so.many.dots.you.can't.find.your.way.home hell, for that matter.

[LCMark]

@mwieder: lol - with hindsight it probably should have been multiWordCamelCasePropertyNameHell - probably would have illustrated my point better

[mwieder]

Another option (I don't particularly like it, but I think it should be mentioned) is something like the way the xml parser specifies child nodes. So we'd end up with

Code: Select all

get the controlIDs(1) of group "xyzzy"

to get just the first-level child controls or one of

Code: Select all

get the controlIDs(-1) of group "xyzzy"
get the controlIDs of group "xyzzy"

to get the whole set. That wouldn't change the current behavior and has a minimum impact on the parser without introducing a new vocabulary.

[monte]

Well I'm easy either way as long as we get the property. The main problem I see with using controlIDs for a non-recursive list is it mains it will be virtually impossible to come up with a name for a property to return the full list like the number of controls. I think given none on the current IDs|Names properties recurse there's a precedent there. Having both might be useful (which is what I've done).. in some cases you just want to loop over all the controls and don't care if some are in a group or not.

[LCMark]

I think the safest course of action is to go with 'childControl*' for the non-recursive versions. It allows the most future flexibility - we can always deprecate that property or make it a synonym for something else sometime down the line. (I think we can live with the 'slight' discontinuity of 'groupIds' for now - it is essentially meant to be akin to 'sharedGroupIds' and 'backgroundIds' which don't recurse since only top-level groups are relevant so there's an element of consistency there).

Anyway, I'm going to go ahead and merge in Monte's pull-request

[monte]

Great... and you're sure I can't interest you in the unsharedChildControlIDs of card?

[mwieder]

Shouldnt that be Card.Controls.Child.Unshared.IDs ?

[monte]

lol... yeah, I know it's a ridiculous name but I'd really like to be able to recursively parse a stackfile without having to check if a group id is among the lines of the sharedGroupIDs of the card...

[LCMark]

Hmmm - can't you just derive this information easily enough from the groupIds and the sharedGroupIds... A group is unshared if its in the groupIds of the card, but not in the sharedGroupIds. Indeed, this creates the list for you:

Code: Select all

local tUnsharedGroupIds, tSharedGroupIds
put the groupIds of this card into tUnsharedGroupIds
put the sharedGroupIds of this card into tSharedGroupIds
split tUnsharedGroupIds by return as set
split tSharedGroupIds by return as set
repeat for each key tKey in tSharedGroupIds
    delete variable tUnsharedGroupIds[tKey]
end repeat

[monte]

Sure we can get it multiple ways... like we can with the childControlIDs etc but it occurs to me that when you want to iterate all the controls in a stack you want to do it as fast as possible so anything we can do to speed that up is a help. Something as fundamental as recursively iterating a stack should be supported at engine level in my opinion and right now you can't ensure you only parse each control once unless you check for shared groups...

[mwieder]

@Monte- I'm not sure I agree with this. Iterating through the lists isn't something that would normally be done except when working in the IDE (although I'm sure there are some edge cases you could come up with), and I don't see that as rating a push into the engine. Normally I'm all for speeding things up, but I think the minimal speedup doesn't warrant the added complexity of adding a new keyword into the engine. The scripted solution seems to fill the need - if that weren't possible then things would be different.

[monte]

I would like to document that controlIDs, childControlIDs, sharedGroupIDs, cardIDs and their name counterparts all return the list in layer order so that the feature can be relied upon in future implementations. I'm relying on this in lcVCS. Is everyone agreeable to that?

[mwieder]

Sounds good to me. The lists can be sorted into numeric or alphabetic order if necessary.
It does bring up a slight conundrum, though, in that the list can't be sorted back to layer order, but I don't see that as a stumbling block.

[monte]

I'm not sure why you would want to sort them or if you did why you would want to sort them back

I suspect it's always going to be simpler to return them in layer order because layer is represented by the linked list of controls but as its not documented I don't like relying on it.

[LCMark]

@monte: I think it is reasonable to specify that these lists will be in layer order - indeed, the 'number' / 'layer' property the engine can return is calculated by stepping through the linked-lists in these cases. Even if the internal data structure changed in some fashion that meant this wasn't the case there would still need to be an iterator of some sort to step through them in layer order for rendering (and searching!) purposes.

@mwieder: You can still sort them back:

Code: Select all

put the cardIds of this stack into tCardIds
sort the lines of tCardIds by random(1000000)
sort the lines of tCardIds by the number of card id each of this stack