Rugged ID

[monte]

I implemented rugged id as an object reference you can get:

Code: Select all

get the rugged id of button X

https://github.com/runrev/livecode/pull/39

@runrevmark wanted me to bring it here to discuss it here:

I think the 'rugged id' might need a little more thought. If the idea of 'the rugged id' is to return a condensed control reference that identifies the control then it can't just be 'control id of stack'... The contents of a control's properties can depend on the card (i.e. field text, button hilite) thus using 'the rugged id' as it currently stands will lose information - it probably should be 'control id of card id of stack'...

I'm not sure what the answer is here. Other than shared fields and buttons adding the card id actually makes the reference less rugged. I'd be happy with the property just not being able access unshared properties other than those on the current card of the stack or first card the group is on... Either that or provide a way to get all the values for unshared properties.. like in an array keyed on card id... that would be handy for lcVCS actually... could I do that?

[LCMark]

Well, discussions about getting all instances of shared properties is perhaps a different discussion

My point here is that if 'the rugged id' is toted as being the simplest reference needed to preserve what a control is, then it missing out the 'card' means it fails in this regard for controls that could be shared. Also, given that a control can go from being shared to non-shared and vice-versa dynamically, it means such references could 'break' (assuming they are using the rugged id to fetch text, hilite etc.).

Basically, what is the purpose of 'the rugged id', why is it a good idea to have, and is it still a useful thing to have given the issues with sharedness (assuming including the 'card' reference makes it no better than 'the long id').

[monte]

I think the point of a rugged id is it doesn't matter how its groupedness changes or even what card it's placed on and removed from it's still a valid reference to an object. The fact that you can't access all values of a couple of properties just needs to be documented in my opinion...

[mwieder]

Unless we're talking about something else here, I'm not at all wild about the idea of the "rugged id", at least as currently implemented, i.e., using the short name of a stack as a unique identifier. I think this is a case where the uuid discussion converges. A uuid would uniquely identify an object and eliminate the need for further qualification.

[malte]

Unless we're talking about something else here, I'm not at all wild about the idea of the "rugged id", at least as currently implemented, i.e., using the short name of a stack as a unique identifier. I think this is a case where the uuid discussion converges. A uuid would uniquely identify an object and eliminate the need for further qualification.

+1...

However, rugged IDs (ideally unique) would be great to reference behaviors, in situations where you have the behavior button is loaded *after* the stack containing the control that has the behavior is loaded.

[mwieder]

@Malte- yes, I'm not saying we shouldn't have something *like* a rugged id, I'd just like to get rid of the "short name of stack" reference. At least as much as possible. As much of a source of conflict as it is now, I think this will only get worse as the user base expands. It's an item of technical debt and this might be a good time to deal with it.

[monte]

You are certainly right that the UUID discussion does have a lot of crossover with this. I guess rugged IDs are being used because we don't have UUIDs. I just thought because rugged IDs are being used and because UUID support is likely to be a long way off if ever then some engine support would be handy.

[monte]

If nobody else supports this then the pull request might as well be closed

[rkriesel]

... Either that or provide a way to get all the values for unshared properties.. like in an array keyed on card id... that would be handy for lcVCS actually... could I do that?

You can. In the context of the following command, there are repeat loops for each card and control of a given stack.

Code: Select all

command assimilatePropertiesForControlOnCard @rArray, pCard, pControl
    switch word 1 of the name of pControl
        case "field"
            if not the sharedText of pControl then
                put value( "the text of " & pControl & " of " & pCard ) into rArray[ pCard ][ "non-shared text" ][ pControl ]
            end if
            break
        case "button"
            if not the sharedHilight of pControl then
                put value( "the highlight of " & pControl & " of " & pCard ) into rArray[ pCard ][ "non-shared highlight" ][ pControl ]
            end if
    end switch
end assimilatePropertiesForControlOnCard

-- Dick

[rkriesel]

... My point here is that if 'the rugged id' is toted as being the simplest reference needed to preserve what a control is, then it missing out the 'card' means it fails in this regard for controls that could be shared. Also, given that a control can go from being shared to non-shared and vice-versa dynamically, it means such references could 'break' (assuming they are using the rugged id to fetch text, hilite etc.).

Basically, what is the purpose of 'the rugged id', why is it a good idea to have, and is it still a useful thing to have given the issues with sharedness (assuming including the 'card' reference makes it no better than 'the long id').

The purpose of rugged ids for me is making sure that any object references that I code will survive any reorganizing and renaming within the stack. So I see rugged ids as fundamental to allowing group structures to evolve without breaking code, at least until uuids come along. But uuids don't resolve unshared properties either, unless fields and buttons have different uuids for every card they're on.

I'd agree that the rugged id is the simplest reference now available to preserve what a control is. I don't see unshared properties as part of what a control "is," but instead as relationships between controls and cards.

-- Dick

[rkriesel]

If nobody else supports this then the pull request might as well be closed

I support it, Monte. Its syntax is, I think, a worthwhile improvement over invoking function RevRuggedID, and it deserves any attention it'll get in the dictionary (presuming the dictionary will be kept up).

-- Dick

[mwieder]

@Dick - uuids implemented for id purposes are, I think, right around the corner.
I don't like the idea of institutionalizing rugged ids in their stead. Encouraging their use at this point when we're so close to having uuids for the same purpose would be bad for a few reasons:

1. rugged ids are more brittle than uuids as unique identifiers.
2. rugged ids enforce the idea of a "short name" representation of objects, and this is particularly bad when referring to stacks.
3. rugged ids are currently used by the engine only for behavior references; replacing this mechanism with uuids instead gets around the shortcomings of rugged ids.
4. if we make rugged ids official, developers will start using them in their code in place of uuids, and I think we want to discourage this (sorry) iin favor of uuid references.

While I see your point about having object references survive object renaming, uuids also neatly solve that problem.
I don't understand the "reorganization" problem... can you help me out with that?

[monte]

Which corner? I think runrevmark is still resistant

[rkriesel]

I don't understand the "reorganization" problem... can you help me out with that?

Early in a new project, controls other than groups proliferate, leading to new schemes for organizing them into groups, which means new groups that break code containing long ids.

So as I see rugged ids, they facilitate evolution -- until something better comes along, such as uuids.

Do we have a clear statement of the reasons for hesitating to adopt uuids?

[mwieder]

The uuid() mechanism is in place now. Replacing the current ids with uuids is a bit more of a chore (see the thread on uuids). But it's coming, and it's a necessary part of moving the engine forward. When the task is done it should eliminate the need for anything like rugged ids, so I see this as a non-issue except as a temporary measure, followed by ruggedID returning a uuid form. I think it's a side-road we don't need to go down.