On 2008-12-12, at 14:16:55, has wrote:
Did look for earlier posts but missed that one. Comments on it:
'Provider' is a better choice of phrase than 'terminology provider' inasmuch as the latter is actively misleading. The terminology retrieval aspect is merely an implementation detail - a workaround for Apple events' use of cryptic four-char-codes instead of human-readable strings as symbols. The major goal of any import mechanism is to provide programs with access to additional functionality. 'Functionality provider' would be a better choice that 'provider' in that at least it gives some clue as to what is being provided.
I agree that 'provider' is the more encompassing term. But I intended the facility to handle both implementation and terminology.
associate stadds with provider "com.apple.osax.standardadditions" set command_list to commands of stadds properties of item 1 of command_list
The reason AppleScript uses the word 'application', for example, is that its meaning is immediately obvious to any Mac user,
Then another term which gives the user an equally obvious association must be found:
vocabulary provider
It's been established that the concept is understood by the person to whom it was meant to be communicated.
It's also assumed that if you're posting on a public forum that additional feedback is acceptable or even actively sought. (Whether or not it's what you'd like to hear is another question, of course.:)
Yes, but replying to C. Page's posts brings up a reply to the list only. For someone asking that an historical wrong be addressed, it's probably best to submit to the place he or she would seem to prefer.
I think I understand it well enough. As far as I can tell, you are actually proposing several things:
Yes.
1. You are proposing that osaxen are treated as individual namespaces within AppleScript in the same way that applications already are.
More than osaxen but not in the same way that applications are.
associate some with provider POSIX path of ((path to library folder from user domain as text) & "Scripts:some.scptd")
Apple makes a leap:
associate cf with provider "/System/Library/Frameworks/CoreFoundation.framework/"
The significant notion is that the binding is _not_ to a process (i.e an application) but rather to a unique identifier consisting of a user defined namespace prefix and a URI supplied by the target vocabulary provider. It would be the responsibility of the scriptor to arrive at unique prefixes and we have to presume that any code hunk wishing to be eligible to be a provider has its bundle identifier in order.
This would do three things:
A. avoid polluting AppleScript's globally available terminology
Yes. Avoid collisions.
B. avoid osax commands being sent to any process other than the one running the script
I didn't say that or even mean to imply it. That decision will have to be made by the AppleScript team according to policy. What I didn't specifically state though was that normally namespace implementations (C++, Tcl, and XML) come with nesting capabilities of one sort or another:
associate fndr with provider "com.apple.finder" associate stadds with provider "com.apple.osax.standardadditions"
tell fndr associate st with provider "com.apple.osax.standardadditions" end tell
set f to fndr::st open for access hfspath
C. break backwards compatibility with all existing scripts that use osaxen.
Not at all. The goal is to provide certainty as to the environment in which they will be executed. Providers can be con-mingled with the current calling conventions.
2. You are proposing that an extensible mechanism for connecting to different types of resources (applications, osaxen, frameworks, etc) is added to AppleScript.
Yes.
3. You are proposing that scripts target all classes of connectors using the same one-size-fits-all interface.
Yes.
You're also implying that an extra layer of indirection be added between identifying a provider and using it, so that instead of writing:
tell PROVIDER ...
users now write:
associate PROVIDER_NAME with PROVIDER
(* a bunch of other code in here *)
tell PROVIDER_NAME ...
Well, yes and no. You could certainly use full addressing:
tell provider "com.apple.finder" doit end tell
There could be possibility to supply preset providers by using an Info.plist or sdef entry.
To summarise:
- You are proposing significant/major changes to the language.
No. I'm suggesting a new built-in class which provides the capability to address the historical problem, isn't bound to a ProcessSerialNumber directly, and has a few other conveniences which may be implemented at leisure once the main idea gets implemented.
- These changes involve significant/major development costs.
It's just a class. I think the most time would be spent adding the namespace delimiter to the allowed symbol characters (and please think about a few spares like "%", "@", "$", etc.). Remember that gcc has a setting to enable $ in indentifiers if stuck.
- These changes involve significant/major disruption to existing users.
No.
- These changes make the language less attractive to non-programmers (its major audience and raison-d'être).
Beauty is in the eye of the beholder. If the emphasis was that the primary form of address was to a vocabulary provider rather than an application, then I don't find a conceptual problem.
- These changes still won't make the language any more attractive to professional programmers.
Wild speculation.
- Concrete benefits (as opposed to theoretical ones) will be measurable somewhere between modest and minimal, and far outweighed by the above costs.
More speculation.
I'm not trying to be mean for the sake of it,
Ok. Have a nice day. Philip Aker
Democracy: Two wolves and a sheep voting on lunch.
|