propertynames

[mwieder]

Pete doesn't have time to open this topic, so I'm doing it for him.
Over to you, Pete.

[monte]

lol... that's good because I don't have time to implement it... over to you anybody else...

[mwieder]

While you're at it, could you please not find time to implement synonyms?

[monte]

I heartily promise not to do it while I'm not doing the rest of it

[phaworth]

OK guys, well I guess I'm disappointed at the closemindedness you're exhibiting, seems in direct contradiction of "open source". Just because you can't figure out why someone would want to do something doesn't mean that someone out there DOES want to do it. Why would you build a brick wall around something that prevents someone from getting hold of a specific piece of information that is an inherent part of Livecode? SYnonyms exist, there should be a way of finding out about them.

Mark - you're misquoting what I suggested. The key word you omitted is "optional". I did not insist that synonyms be returned, just that there be an OPTION to get them. Why does that cause you such a problem? You don't want them? Then don't request them, simple as that.

Think about SQL - the entire structure of an SQL database is available to anyone who wants to discover it. Do you think the implementors thought "oh, nobody would ever want THAT piece of information?" No, they made everything available so that anyone who had a need for it could have access to it.

So go ahead, implement what YOU think is best, I don't have any more time to waste on this.

[mwieder]

@Pete- hi and welcome to the party.
Now that you're here, can you explain to me why you need synonyms in the propertynames? I haven't wrapped my head around that. For me synonyms are something you look up in the dictionary as needed.
Unless I missed something (and given my week that's almost a certainty), they aren't something you need for your stack browser.
So I could use some help with this.

[LCMark]

I think (reading between the lines and posts elsewhere) what @phaworth has identified as missing is the ability to ask for a complete description of the object's properties and what they are and how they relate to each other. The issue here is that a simple list of property names doesn't give you this information (again, reading between the lines, this is the cause of the pushback against 'synonyms').

For a long time 'the properties' has been incomplete and inconsistent and I think (to a very good degree) the work @monte has done has now resurrected it with a distinct purpose and describable definition. Indeed, the breakage @phaworth experienced in 6.1-dp-1 was due to an oversight rather than an explicit choice (and since it was a dp, that's fine - this is the purpose of them).

So, the question comes back to this - what information would you like from an object? And, also, how do you want to use that information?

[mwieder]

Well, I'm still confused then. I thought the breakage was with "the properties", not "the propertynames". Currently the propertynames is a bit of a mixed bag - there are some synonyms in there already ("abbr", "backcolor", etc.), but not all (no "cd", etc). I don't see the need for the repetition, but apparently Pete needs this and more as an option. That's why I opened this topic for discussion.

I wouldn't mind "the propertynames of <object>" returning a list of properties that apply to that object, but I think it's going to be difficult to manage that with the dynamic list of getprop/setprop handlers that modify what applies to objects. This isn't a problem, I think, for the list of "the properties", at least in a version control sense, because there the list is only the static properties that need to be applied when creating or recreating an object.

[DarScott]

When I need to look at the cipher names, I type 'put the cipherNames' into the message box.

I wonder why. I could go to "encrypt" in the dictionary. (I just did, and the names are not there.) Maybe I have a gut feel that the dictionary lags. In the case of ciphers, in contrast to properties, maybe the implementation even dynamically discovers them, so my analogy is crumbling a little.) I went to straight to the final reference, in a sense. Maybe I could have gotten the same information scanning revisions backward in time to some root document, but that might not work. In the case of ciphers names, it might be handy to use the function to fill a menu. Of course cutting and pasting from a document, would work, too. That has the advantage and disadvantage of no surprises as the engine evolves.

This prompts in me a consideration of what the engine development product is. Perhaps it is both a change or addition, plus a revision of some crisp reference. That, the reference, perhaps made up of several documents to ease merging, is part of the git processing. A developer (or a small team) must make the appropriate changes to the reference. The reference would be the penultimate authority and should match the ultimate authority, what happens in testing, though that might be considered to be the other way around--there might be bugs.

A person can go to the reference.

IDE developers, plugin builders, book writers and dictionary workers and so on can use that reference for the features those provide. (It might be that the reference is the dictionary, but that can be a burden, but maybe not.)

Much of that reference can be in the engine and even provided by the engine. The ___Names() functions might be part of this. I'm not sure.

So, where there is a need, that need might be satisfied by the total package of engine development, the pair product, the engine and the definitive knowledge about it. Some needs might be satisfied by a better representation of the definition, the reference.

[mwieder]

I think the engine should be the authoritative source. So the dictionary should get its information from the engine, and then developers can go to either place and they'll be in sync. I also think that having the information flow from the engine means that it's possible to get hint information in the IDE, and by reference, in plugins or other stacks. This is a Good Thing.

I'd like to see "the propertynames of <object>" implemented, but I think there are a few complications with this.
First of all, the compiler has to be happy with the syntax.
And secondly the issue of getProp/setProp handlers enters into this. Should they be returned in the list?

[DarScott]

I wonder what it means for the engine to the the ultimate authority. Should there be the function commandNames()? Should we be able to write this:

Code: Select all

get the description of "annuity"

I don't have a strong feeling, except that the engine and a reference document, as a whole, is always complete. (I have used the word reference, but other words might be better, like definition.) I do lean against adding things, but this is intriguing.

Perhaps such a description, if this is done, is complete but minimal. Anybody adding or changing commands or properties would include the revision to the description (unless making the behavior match the description). Maybe the description would live in the source near the code.

Even if a small step is done now, pondering the big picture might be handy.

[mwieder]

There is already. "Get the revAvailableHandlers of <object>".

[DarScott]

That function returns 'true' on 5.5.4. It is not in the dictionary. And, as a rev prefixed command, doesn't that mean it is implemented in a separate library or available only on the IDE?

[mwieder]

I haven't looked, but I'm guessing it's in the engine, since it can get all this from protected scripts as well.

[DarScott]

OK. Thought when I wrote commandNames(), I was thinking engine commands in the context of it being self documenting. I don't know whether it should be, I don't mind a closely tied document in the git.