>>Mark>>Given that the correct choice of attribute or whatever can't be made until runtime, it seems like the design flaw lies in allowing the same English word to compile to different things in different contexts.
>>Has>>>Yes. Exactly.
You say design flaw, I say design feature. Before appleScript applications with their own scripting languages had commands like this:
printPage printDocument printRange printSelection
Each of those were verbs and the application vocabularies or dictionaries were huge.
AppleScript is designed so the scripter types "print" as a verb and page or document, etc. as a noun. Suddenly the same English word can be used to act on multiple objects.
Not just that, but the same command "print document" for example can be compiled and executed in hundreds of applications. Similarly, you don't need to learn how each different application refers to a character or a pixel or print setup or whatever. You can use the same keyword in each context.
This is the same english word, compiling to different things in different contexts and one of the things that makes AppleScript AppleScript. This feature can be complicated by terminology conflicts, when an installed OSAX has the same keyword as an application. But, again those are very rare and easy to diagnose and workaround.
>>Has>>>[1] Since AppleScript is a weakly, dynamically typed language, the only time it can know for sure what 'year' (as in 'year of <something>') means is when it actually applies it to an object at runtime. However, in order to create its English-like appearance, it makes a best-guess about the user's intent for that word according to where it appears in the script: if it appears within the 'tell app "iTunes"' block, it gives it one meaning; if it appears outside the block it gives it another. If it guesses wrong, the script fails at runtime.
>>me>>All this is sort of true, but most of it applies only when there is a terminology conflict, which is remarkably rare, even without the watchful eye of the apple event registrar.
In all fairness, it dawned on me that there are cases where the compiler must "guess" what the scripter intended and sometimes gets it wrong.
Here's an example:
set x to z of y as string
The compiler must guess if the scripter meant:
set x to z of (y as string)
set x to (z of y) as string
In this case the scripter can use parens to avoid guess work, and this is not related to terminology conflicts.
ES
=
|