Re: terminology conflicts, etc. [was: Re: A date IS a date]
Re: terminology conflicts, etc. [was: Re: A date IS a date]
- Subject: Re: terminology conflicts, etc. [was: Re: A date IS a date]
- From: has <email@hidden>
- Date: Tue, 12 Feb 2008 14:13:32 +0000
On 10 Feb 2008, at 18:30, Ed Stockly wrote:
>>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.
Sorry Ed, but you've clearly not understood anything I've said. The
advantages of 'verb-noun' separation, otherwise known as Polymorphism
101 and hardly unique or original to AppleScript, is *completely and
utterly irrelevant* to the issue of how the AppleScript compiler
parses AppleScript source code and decides what each word means.
Please either stay on topic, or find yourself another discussion to
participate in because I'm getting tired of hearing the same clapped-
out AppleScript apologetics over and over again whenever I try to
discuss AppleScript's problems and what can be done about them.
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
No, simple precedence rules will take care of this. It requires no
special insights, external knowledge, hidden cheats or guesswork for
either users or AppleScript to parse and execute this statement.
(Assuming that 'x', 'y' and 'z' are all variable identifiers and not
application/osax/language-defined keywords, of course; if they are
keywords, any simple, reliable interpretation all goes to crap again
for the reasons I've previously discussed.)
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
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