I have a need for making my own records in a list,
each will contain two items, an index, or a “key”, and data.
If you run the example below, then you’ll see that the data is coloured in one color,
and that index is coloured purple, so, I guess data is a keyword, and index is a property.
But will this affect me, as along as I don’t use the records from within a scope of something
that uses those keywords for something else?
Thanks.
set n to 1
set v to "something"
set l to {}
set end of l to {index:n, data:v}
set {index:i, data:v} to item 1 of l
set l to rest of l
It is a shame I can’t make the pipes stick. In my case I wanted to use the word priority as a property of a record. Since I have nothing that uses the word priority on my machine, I can’t put pipes around it. I still found this practice to be better than use number or integer to make the pipes stick, because I believe the probability for someone else to have taken such measures to be higher, than to inadvertently bump into “priority”.
Let’s take a look at the records:
{name:“hello”, index:1}
→ { ‘pnam’:“hello”, ‘pidx’:1 }
When we use user defined keys:
{|name|:“hello”, |index|:1}
→ { ‘usrf’:{“name”, “hello”, “index”, 1}}
When defined and used in the same scope there is nothing going to happen and it’s safe to use record properties (enumerated keys). The meaning of the record, when it’s only used by the script doesn’t really changes. The only problem that can happen is that when a command wants user defined keys as it’s parameter, the given format is then wrong and cannot be handled. For that reason, and to make a clear distinction between enumerated keys and user defined keys, the rule has becomes always use pipes, never enumerated keys. But the rule is mostly for people who have no clue what’s happening on the background and getting unexpected results, which is the average AppleScripter. So even if it’s safe to use enumerated keys in records, I never recommend others to use them.
Normally when you have user defined keys, pipes are automatically wrapped around them when enumerated keys are installed in the mean time (stored as compiled script).
Thanks for the explantion. I interpret that as I would have been good, even if had used “index” for instance as a property in a record, but that I would have had to use pipes, should I have used it as parameter to a handler.
And if I am using priority, (without pipes), then pipes will be added, if something with a dictonary that contains priority, pops up on my machine.
I think you forgot to mention one case however, and that is when you create/extract properties from something, if there is an absence of pipes then, then I believe that the property for the label, can come back as a badly coerced data type.
I have to get some better grasp of this, which is why I asked in the first place.
I wouldn’t think in pipes and non pipes, that’s uncompiled code format. During compilation the code is changed in either two formats (like in my previous post) or an hybrid of it, but no distinction in pipes and non pipes anymore. So it’s really a matter of how the record is compiled actually. When the call is made and the enumerated values have no matching dictionary but the target still support the key, there is still no problem. Keep in mind that a dictionary is only used when compiling the code (read: determine to use pipes or not). Also the user defined keys won’t change in enumerated keys, as long as you don’t recompile your script (and will be corrected when opening, and the lexicon has changed). So the chance that something like you mention actually will happen is very small and what I can think of can only happen when an application or osax has been updated and some parameters requires another format which is something that happens very rare.
Thanks for the clarification. I understand this as, my code have been compiled with pipes, even though the pipes are removed from the source text of the code afterwards. The compiler did that, because there weren’t anything conflicting around. This means that I should rather post uncompiled code, (with pipes), to ensure that it is compiled with pipes on a users machine, so that no conflict can ever happen. -The conflict can’t happen, because of some unanticipated usage, like creating an object inside a scope with something that has a “priority-something”, -because then, the invisible pipes takes effect.
Correct, in compiled code there is are no pipes, it’s either user defined keys or enumerated keys. So it’s “better” to remove them when not needed.
Yes, the compiler reads an user defined key and will only wrap pipes around them if the name is in conflict with enumerated keys.
For that reason we have sometimes problems posting code because some people have certain scripting additions installed. XML Tools uses “NSXML” word (shorthand for Name Space XML), a term that can be used by AppleScriptObjC as well, so it’s therefor not only keys in records that can be in conflict with enumerated values, also other types can be be in conflict as well. So to post safe code you shouldn’t only wrap around user defined keys in record but also properties, globals, locals, handlers and scripts. Of course, the code that will be posted here wouldn’t look that pretty
Excactly. The problem only appears to happen when storing scripts as uncompiled code (.applescript files). Because on source code format there is indeed a distinction between piped and non piped keys. Again, in compiled code there is no distinction because there are no pipes.
You’re welcome and thanks for the interesting question. The question itself is very interesting for every MS user. Because in practice this goes wrong when someone clicks the “open in script editor” link on MS.
But the pipes, or bars if you like, are compiled into the script, before they do disappear in the source text, so they are there, even if they aren’t visible, because what is presented in the Script Editor, is the source text.
Hopefully such “collisisions” are most likely to happen with record properties, and not with variable names.
And such themes are interesting, agreed whole heartedly.
