So, for my own benefit here, was I at all wrong? And I understood before about parentheses except I like to be proper in my own mind 
Shane and Richard,
So, now I’m confused too – I thought I had figured this out by overriding the getter, and seeing what syntax would cause that getter to be called. The docs talk about the fact that with BOOLs, if you have a property called prop, the getter can be isProp as well as just prop (in Objective C) – in ASOC you can’t have a method with the same name as the property but isProp() works to override the getter, and not just for BOOLs. In the example that we’re talking about in this topic, I created the override method in the HelperClass:
on isErros()
log "got to getter"
return erros
end isErros
In the app delegate, if I write "log helperClass’s erros, I get the log of “got to getter”, but if I write "log helperClass’s erros() I don’t get the log-- hmmm… this is the opposite of what I expected.
But then I tried accessing the getter from within the HelperClass where the getter is defined. Within an ASOC script, to access a getter, you have to say something like “set var to valueForKey_(“erros”)” or you can use “self()” like this: set var to self()'s erros – interestingly, “my” does not work here, so this is a case where “my” and “self()” do not behave the same. Writing “set var to self()'s erros()” with the parentheses does not call the getter. Maybe this doesn’t work because that syntax look specifically for a method erros(), or looks there first and finds the non-overridden implied method and executes that.
Ric
As it does not log anything I wonder if erros() returns a value?
So that implies that using the variable alone means it will look for the various accessor methods, synthesised or otherwise, while using the parentheses makes it a straight method call. Interesting. So…
current application’s NSApp’s isActive() – works
current application’s NSApp’s isActive – works
current application’s NSApp’s active – also works, presumably by trying the various accessor options
current application’s NSApp’s active() – doesn’t work, presumably because it’s a straight method call
That would be consistent with the above.
Ric,
This won’t run on 10.6 because it relies on the new behaviour of class, but it’s interesting:
set x to current application's NSApp's isActive()
log x's class
set x to current application's NSApp's isActive
log x's class
2011-08-05 10:00:29.947 Throw out 6[1069:707] <NSAppleEventDescriptor: ‘bool’>
2011-08-05 10:00:29.951 Throw out 6[1069:707] __NSCFBoolean
Remember than a boolean (and integer) are in Objective-C two values who behaves different from any other. First of all they’re mostly not defined as pointers, they are not objects and they don’t need to be allocated. This makes them hugely different from any pointer to an type (in C) or object (Objective-C). So that they have special treatment through the AppleScriptObjC framework doesn’t really surprise me at all because they have in cocoa and Objective-C too.
No, it’s not surprising – but the the fact that the result is different for isActive and isActive() is, I think, given that they both involve the AppleScriptObjC framework.
I guess the other thing to look at is what happens in both cases if there’s no such method. If you use the parentheses, you get an “unrecognized selector sent to instance” error, and if you don’t, you get “this class is not key value coding-compliant for the key …” and a full-on exception thrown. In debugging terms, there are pros and cons to both.