• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: terminology conflicts, etc. [was: Re: A date IS a date]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: terminology conflicts, etc. [was: Re: A date IS a date]


  • Subject: Re: terminology conflicts, etc. [was: Re: A date IS a date]
  • From: Ed Stockly <email@hidden>
  • Date: Sun, 10 Feb 2008 10:30:55 -0800

>>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





=
 _______________________________________________
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

  • Follow-Ups:
    • Re: terminology conflicts, etc. [was: Re: A date IS a date]
      • From: has <email@hidden>
    • Re: terminology conflicts, etc. [was: Re: A date IS a date]
      • From: Luther Fuller <email@hidden>
References: 
 >Re: A date IS a date (From: Ed Stockly <email@hidden>)
 >Re: A date IS a date (From: "Mark J. Reed" <email@hidden>)
 >Re: terminology conflicts, etc. [was: Re: A date IS a date] (From: has <email@hidden>)

  • Prev by Date: Re: PHP and Applescript
  • Next by Date: Re: Error -609 [OT]
  • Previous by thread: Re: terminology conflicts, etc. [was: Re: A date IS a date]
  • Next by thread: Re: terminology conflicts, etc. [was: Re: A date IS a date]
  • Index(es):
    • Date
    • Thread