Does it stay that way after compiling/saving? I know in Xcode 3 you could just write “end” and when saved it would fill in the handler/method name for you.
I confirm that the method’s name can be omitted in XCode 4 after the END statement.
on myHandler()
end myHandler -- OK
on myHandler()
end -- OK
on myHandler()
end myHandler() -- [b]NOT OK[/b]
on myHandler_(sender)
end myHandler_ -- OK
on myHandler_(sender)
end -- OK
on myHandler_(sender)
end myHandler_(sender) -- [b]NOT OK[/b]
What you’re seeing is just a reflection of the lack of a compiling editor in Xcode 4. You can put in whatever you like, as long as it compiles. Typing just “end” has always worked in AS in that compiling adds the rest automatically.
It’s just like Shane says. After compiling the ‘missing’ code will be added. Everything script editor can complete, your application can complete too. Tell app “finder” is the same as tell application “finder” only when ‘compiling’ in script editor it changes to app to application. Because applescriptObjC only needs to be compiled at runtime you’re working you’re working with plain text files. Remember that this can give you troubles in the futore. This completion of applescript can give you sometimes strange result. It’s not only the end blocks that are completed it sometimes complete parentheses on places you don’t want them.
In Applescript language, what follows the end statement is optional: end [ repeat ]. So consider this as correct (and will compile in XCode):
script TESTAppDelegate
on myHandler_(sender)
if true then
repeat with n from 1 to 5
log "It works!"
end
end
end
end
The script editor adds the optional terminations:
script TESTAppDelegate
on myHandler_(sender)
if true then
repeat with n from 1 to 5
log "It works!"
end repeat
end if
end myHandler_
end script
Very kind of it, but not strictly necessary for XCode 4. If you get lost, you can use a trick from another programming language, as:
script TESTAppDelegate
on myHandler_(sender)
if true then
repeat with n from 1 to 5
log "It works!"
end -- repeat
end -- if
end -- myHandler_
end -- script
But this is just a detail, not even annoying. What is really missing is some effective compiler checking like:
on myHandler_() [error xxx : missing parameter]
set n to myControl’s integerValue() [error xxx : NSNumber must be coerced to integer]
myControl’s drawCellInside_(myRect) [error xxx : parameter of drawCellInside: must be of type NSCell]
Most of them are semantic checks and are not possible in AppleScript because there are no such checks in AppleScript nor it’s compiler. Semantic checks must or is quit handy for compiler languages who are vary static languages. A function can only return one type of value a char, object type or integer for instance. Applescript is allowed to return any type of object/value so semantic checks is simply not possible.
Maybe the missing parameter could be solved but it is according to applescript language guide not against any rules.
Keep in mind that what you see in, say, AppleScript Editor is the result of two steps: the content is compiled into a compiled script object, and then that object is decompiled to produce the (styled) source that replaces your original source. It’s the compiled script that is actually run. Xcode 4 is just skipping the last bit.
That’s not so bad, but of course has its counterpart. I suppose (just suppose, never tried) that Objective-C is more strong-typed?
I suppose, too, that XCode and AS compilers are not the same. What does XCode compiler? Does it translate ASOC code into ObjC? What kind of “script object” do we get at the end? Just an amateur question.
First of all Xcode isn’t a compiler. It uses the gcc compiler for C and it’s supersets. Then gcc is a compiler while, applescript uses an interpreter. The difference between those two are there from the start. Even if applescript has the option to compile and OSACompile installed it isn’t close to a compiler. No it isn’t converted to Objective-C, AppleScriptObjC.framework is acting as an bridge. You call a method or object and the framework will do the actual call. Basic objects can be converted with this framework so a NSString as string will be coerced to an AppleScript object. I’m not sure what you mean with ‘what kind of script object we get at the end’ but I can tell you that there isn’t a special object or anything the only thing that is special is the bridge in between. The connections and bindings are stored in Objective-C at build time and can’t be altered (you can’t alter the source code like you could with builded studio apps). When running the framework looks for the connection and re-connect them with your script. So again the script (object) itself isn’t special.
That’s true, although what we refer to as compiling does convert it into a sort of intermediary bytecode that is then interpreted.
Also true. But my guess is that the call [[NSBundle mainBundle] loadAppleScriptObjectiveCScripts] in main.m results in the AppleScript “class” files being read, and true Objective-C classes being constructed by the runtime with the AS “class” names. I suspect these classes then call the original AS code when required. So in that sense, some conversion is going on.
So what are the complaints against XCode? Lack of pretty printing? “Compiler” errors? What more?
I searched on the Web for some external editors capable to do with ASOC what Script Debugger does with Applescript and found nothing. If you try Script Debugger with ASOC it stops very fast – in fact at line 2 (property parent : class “NSObject”) :rolleyes:
Yes that true. I can’t find the actual code or documentation of how the framework works but our thoughts about it are the same. I was referring to Fiz about the file stored in /Contents/Resources/class.scpt and that there is nothing special about that file. Because Objective-C is an compiler language there isn’t an eval like interpreted languages have. It is not possible that there is a source generated en then passed to an eval to make it a Objective-C class. Even Objective-C is smalltalk based which makes it much more dynamic than many other compiler languages, creating a new class and then allocate it (create object) is not possible at runtime. The class itself needs to be defined at build time. So I think NSSelectorFromString and NSInvokation are the two most important methods the AppleScriptObjC.framework uses.
Well I told you that there I’m not complaining much because Applescript is the only language for me that had to do a step backwards while the other 3 languages, I use Xcode for too, have been improved but I forgot about 1 thing when I worked in xcode 3.2 again yesterday. There is is in the contextual menu when you’re in the source code a menu item ‘jump to definition’. I always preferred this above the documentation and is much faster to work with. But in Xcode 3.2 when I lookup where int is defined for example I could choose which file and look which file overrules another. This can’t be done in Xcode4, also for applescriptObjC, you can’t use jump to definition, the documentation is much more slower than in Xcode 3.2. And I have the fastest available, one week old MBP. So I think it must be frustrating for users who uses an older mac.