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: Jason Bruce <email@hidden>
- Date: Tue, 12 Feb 2008 18:01:59 -0800 (PST)
has,
I don't quite agree with your comments, here. Ed is
saying that it is a feature of the language (not a
design flaw) that the same word can compile to
different things depending on the context, because it
makes the language smaller, which seems to be a
reasonable argument to Mark's comment (note use of the
word "design flaw" in both Mark's post and Ed's),
which makes Ed's post on topic.
Jb
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
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________
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