• 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: Code Completion suggestion
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code Completion suggestion


  • Subject: Re: Code Completion suggestion
  • From: has <email@hidden>
  • Date: Thu, 28 Oct 2004 02:04:18 +0100

Phill Smith wrote:

I agree that there may be serious technical problems but that is what apple is supposed to be about, solving these things to make make it easy for the user.

True. But in this case it would require a large investment for little return, given the amount of work required and the number of folk actually using AppleScript. The economics simply aren't viable when Apple will get far better bang for their buck investing elsewhere, e.g. in a new iApp.



I don't think you examples show these problems though as both of them could come up with useful popup lists containing information from the dictionary. With regards to getting the names or indexes of the objects in the application. Script debugger manages to do this so it must be possible.

It's not too hard to write standalone browsers for exploring application dictionaries and live object models. But what you're taking about is building serious interactive smarts into the AppleScript compiler. That's a completely different task, and the fact that the first is relatively easy to do has absolutely no bearing on whether the second will be easy, hard or practically impossible.



1. There is insufficient type information available in the source code, e.g.:

tell application "TextEdit"
set myRef to document 1's text
...
get myRef's ?????
end tell


here is should come up with

Elements:
character
attribute run
[...]

You know this, I know this. For AppleScript to know this, it would require that Apple engineers implement a type inference engine, plus the ability to silently compile source code on the fly (while ignoring compilation errors due to invalid and incomplete code) so it can run that type inferencing engine on it each time you request that pop-up. That's a non-trivial task and simply not going to happen: there are hundreds of far more basic, far more pressing problems for the AppleScript engineers to deal with.


Here's a far more practical suggestion: improve RealBasic's application scripting and OSA support. Once I finish appscript I'll be happy to talk to anyone that wants to port it to other languages; some of it is sufficiently complete it could even be ported now. And Philip Aker has done good work on making OSA language components easier to write; see <http://homepage.mac.com/philip_aker/osa/osa.html>. Still a significant undertaking, but at least one within the realm of practical possibility.


2. There is inadequate information in the application dictionary, e.g.:

tell application "Finder"
get home's folder 1's ( removed entire contents as I'm not sure what it does)

What it does is completely mess up your desired terminology lookup system, since the dictionary indicates the 'entire contents' property's type to be 'reference', which is hopelessly insufficient for working out what to pop-up next. Right now the only way to get this information is by actually running the code and seeing what comes back, which isn't a practical option for the type of system you suggest.


Regards,

has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: Filemaker changes 04 to 1904
  • Next by Date: Re: Native AS or grep via do shell script?
  • Previous by thread: Re: Code Completion suggestion
  • Next by thread: writing and reading list vars to text file
  • Index(es):
    • Date
    • Thread