Re: Dictionary Inconsistency?
Re: Dictionary Inconsistency?
- Subject: Re: Dictionary Inconsistency?
- From: Shane Stanley <email@hidden>
- Date: Tue, 10 Jun 2014 15:12:33 +1000
On 10 Jun 2014, at 1:16 pm, pscott <email@hidden> wrote:
> What we have here is a failure (of mine) to communicate. I am not saying (nor trying to say) the definition should say "element." I am saying the graph should say "elements."
Why? It's not a table of collections. There's S for suite, P for property, C for command, c for class, and E for element. All singular.
>
>>> So, I don't see how the little square, yellow box called "process" is correct, and I still think the graph is wrong. Where is the error in my understanding?
>> Being too literal, perhaps. The list of elements at the bottom is listing the element collections. They are what you add and remove individual elements from. The table is showing what each element is.
>
> THAT is the crux of the matter. The table (or as I have called it, the graph), appears to be showing what is directly accessible and by whom. I can directly access the commands of a suite, and the properties of a class using the names shown in the table. I cannot directly access the elements of a class as marked by a yellow "E" using the name in the table.
You can in AppleScript, which is what it was originally designed for. The fact that javascript access is always via the element collection doesn't mean the world has to be (or even can be) rewritten according to those rules. An existing object model view is being adapted to serve three masters, and if it's not perfect, there's always bugreport.apple.com.
> And yet, I can directly access the properties and what are CALLED elements of a class using the names shown in the definition! That is an inconsistency. A rip in the continuum.
If your continuum is that fragile, you're in for a rough ride.
>
> I can use your explanation that the yellow "E" does not mean a collection (of elements) called "process", but rather what some collection whose name isn't shown (in the table) contains elements of the class "process".
I doesn't show that, either: it shows the process class -- what every element will belong to. The focus isn't on collections because in AppleScript the concept of collections is mostly irrelevant: there is no collection object as such.
> Or, more generally, "E" doesn't mean a collection named x, it means some collection exists having elements of class x. This makes the table far less useful as a quick reference than if "E" meant a collection (of elements) named x.
To javascript users, perhaps. But if it were changed, it would be far less useful, not to mention very confusing, to every existing user. Or it would mean one thing in js and another in AppleScript, and bang goes your continuum again.
>
> However, I would then have to say that the term "elements" in the definition (as opposed to the table) would more properly be called "collections." The names given there are the names of collections of elements.
That sounds like a sensible change to request in the javascript view.
>
> In any case, I'm beginning to understand the madness. The term "elements" in the definition and the use of "E" in the table both poorly express their intended meaning. However, even accepting these terms for what they really represent, I still feel that the names associated with the yellow "E" would be more useful (as a quick reference) using the name of a collection rather than the name of an element of an unnamed collection.
See above; for better or worse, js is not the only client of this display. Have a look at the .sdef file this display is being built from, and it might give you an idea of the problem. Here's the relevant section:
<class-extension extends="application" description="The System Events application">
<element type="application process" />
<element type="desk accessory process" />
<element type="process" />
<element type="UI element">
<cocoa key="uiElements" />
</element>
<property name="UI elements enabled" code="uien" type="boolean" access="r" description="Are UI element events currently being processed?">
<cocoa key="uiElementsEnabled" />
</property>
</class-extension>
Elements are class types. And later:
<class name="process" code="prcs" description="A process running on this computer" inherits="UI element" plural="processes">
<cocoa class="Process" />
[...]
</class>
That's mapping the AS process class to the Cocoa class called Process; there's no mapping to the application's collection of Process objects. When AS says "process 1", the application resolves the object specifier via the parent when the script actually runs, using key-value coding. But the key to the parent's collection is never exposed by the app, and so there's no way to directly map it to a js collection object. Under the hood, js has to do something like JS object model <-> AS object model <-> Cocoa object model. Any change would be pretty drastic.
(And as a display of an app's object model, ASE/SE has always been pretty spartan, even for AS. That's one of the reasons most serious AS scripters use Script Debugger. No help in js at this stage, but a more useful display of of the object model is the sort of thing that's likely to be done best by a third party.)
> The definition can always be referenced for more information.
The same argument applies to what's shown now.
Look, I'm sure whoever's working on JXA would love some feedback via bugreporter. But I have to say, with admittedly only a cursory glance, there seem to be some far more serious problems than the issue of elements vs collections.
--
Shane Stanley <email@hidden>
<www.macosxautomation.com/applescript/apps/>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden