Such an experiment was already done. See the Java-ObjC bridge. While the heuristic is not automatic– there is a manual mapping to ensure consistency– the end result is the same in that the ObjC APIs are mapped to more “Java-esque” APIs.

It sucks.

The end result is an API that is different enough from the original API that the developer now has the exciting task of having to learn an all new API.

It also lacks consistency. There will always be cases where the mapping rules had to be bent just slightly because of some method naming conflict or API issue.

As a result of that need to manually “bend” the mapping, it yields a bridge that requires lots of tedious “detail” maintenance over time. It also guarantees a significant lag between changes to the underlying layer and updates to the bridge.

There is also a huge hit to dispatch performance. It requires algorithmic string manipulation, including concatenation, comparisons and lookups, before an attempt to dispatch can be made.

In the end, a bridge that perpetuates a very simple and completely consistent mapping rule — substitute ‘_’ for ‘:’, you’re done — is far easier to maintain and will track releases of the mapped API much more closely.

[RWError errorWithString: myString going:kToFile to:filepath];

Becomes:

RWError.errorWithString:going:to:(myString, kToFile, filepath)

This isn’t just a PyObjC transformation, but the actual transformation underlying Objective C. You’ll see experienced programmers refer to methods this way (i.e., simple as errorWithString:going:to:), and some of the introspective techniques (at least in Smalltalk) involve creating these method symbols combined with a tuple of arguments. So PyObjC is really doing the minimal work, providing a one-to-one mapping from Objective C to Python (with _’s).

It would be interesting if PyObjC used heuristics to figure out how to parse keyword arguments, essentially testing all possible combinations, then saved that mapping, dynamically creating functions like:

def errorWithString(self, string, going, to):
  self.errorWithString_going_to_(string, going, to)

going and to can’t magically attain default arguments, though if there are also methods like errorWithString:, or errorWithString:to:, then you might have to grow the method over time, ending up with something like:

def errorWithString(self, string, going=NoDefault, to=NoDefault):
  if going is NoDefault and to is NoDefault:
    return self.errorWithString_(string)
  elif going is NoDefault:
    return self.errorWithString_to_(string, to)
  elif to is NoDefault:
    assert 0, “errorWithString:going: does not exist”
  else:
    return self.errorWithString_going_to_(string, going, to)

Or maybe instead of that assert, we recreate the method, trying to find errorWithString_going_; we could also add a **kw argument, and rebuild the method if unknown keywords are passed. I don’t know how doable this all is, or what the performance change would be (maybe not too bad, so long as the keyword to method mappings were cached)… anyway, it might be a fun little experiment, and can probably be done mostly in Python, so long as some Objective C introspection is already available.

I played with a Python OSA component by Bill Fancher a few years back (2001). It was really cool being able to write Python in the Script Editor.

This was back in the pre 10.1 days - so there wasn’t even Python on machines by default then. It was certainly be an interesting thing to resurrect now, as we have a decent install of 2.3 by default on Panther.

But yes, it’s very sad we have so few OSA languages. Applescript, and Javascript - that’s it (not including Bill’s Python one, because well, it’s not out).

Absolutely. And I think this approach would’ve made Studio much nicer for folk who have a bit of programming experience, but - crucially - at the expense of those who don’t. So I guess I’m glad for Studio users - if not myself - that they didn’t. (And I have to say, something I dislike about IB’s Connections system is it somehow seems to make things look rather more complicated and intimidating than they actually are. Though I can’t quite put my finger on why I feel like this.)

“”"For me, Applescript makes an OK (but verbose) glue language.”"”

AppleScript’s “verbosity” is actually a feature, and a key one at that. Again, you have to consider it in context of its core market, i.e. non-programmers who just want to get something done. For them, a verbose keyword-oriented syntax is far easier to read than a terse, symbol-laden syntax. It enables non-programmers to grok what a script does just by reading the thing - even if they’re not yet familiar with the AppleScript language itself! This is incredibly important to them as it lets them get that first foot in the door with almost zero effort. [1]

That said, there’s no shortage of other areas in which AppleScript does genuinely suck. But let’s not spend the next week going there…;)

“”"I hesitated to write that line about poor object oriented support. Because, in a way, it’s great. You talk to an application (an object) and get its frontmost state (a property). Whose statements are great (where they’re supported).”"”

Actually, none of the above are features of the AppleScript language itself. They’re all features of the Mac’s high-level interapplication communication mechanism as provided by the AppleEvent Manager, which AppleScript hooks into via the Open Scripting Architecture. (This is an incredibly common misconception, btw, so don’t feel bad about it.;)

Basically, any language that can hook into the OS can do application scripting [2]; it just so happens that AppleScript is the most well-known - as well as having what is probably the best and [with some caveats] easiest to use implementation.

One of the interesting things about the AEM is that the application scripting interface works more like a query language than a conventional object model [3]. It just so happens that AppleScript (and, I suppose, others) happen to dress this mechanism up in different clothes. It could just as easily have been done by having embedded SQL-style statements,

“”"A programmer can make their own modules/script objects, with state (properties) as well.”"”

Yup, and it’s great fun for prototype-based OOP. Terrifically liberating. Even if it does feel a bit like running down the public high street with no pants on.:)

–

[1] Just as C’s extremely terse syntax is a key feature for professional programmers who want to avoid getting the dreaded “Cobol fingers”.

[2] Frankly, I think it’s a crying shame that Apple hasn’t done more to push AppleEvents/Open Scripting Architecture support for other languages such as Perl, Python, Ruby, etc. While the actual implementation is less than perfect (IMO), the general concept is absolutely brilliant and doesn’t deserve to be hogged by just a single minor language (especially not one as flawed as AppleScript).

[3] Unless you’re talking about one of the more exotic OO implementations that also have array proccessing-style features built in (e.g. F-Script). The AppleScript language isn’t one of these, however.

I hadn’t twigged that this wasn’t a delegate object. Inheriting from NSApplicationDelegate when instances of the class aren’t going to be application delegates is just silly

The point was that you don’t need to inherit from NSApplicationDelegate ever any more.

For me, Applescript makes an OK (but verbose) glue language. Studio also allows you to use Objective-C/Cocoa concepts when it’s useful (and I’ve done it before - see http://www.wilcoxd.com/blog/archives/000017.html ). That part is pretty cool, to tell the truth.

I hesitated to write that line about poor object oriented support. Because, in a way, it’s great. You talk to an application (an object) and get its frontmost state (a property). Whose statements are great (where they’re supported). A programmer can make their own modules/script objects, with state (properties) as well.

I guess my experiences with Applescript Studio (currently finishing up an application that’s about 3500 lines of Applescript, and 300 lines of Objective-C) are much different from the normal Applescripter who wants a window with a progress bar for their Quark solution.

“”Part of this probably has to do with AppleScript’s poor object-oriented support.”"

AppleScript’s OOP support - which is prototype-based, not class-based, incidentally - is one of its nicer (less unpleasant?) features imo. Doesn’t have a huge featureset, but all the essentials are there and there’s plenty you can do with it. Rather, I think the reason Studio works as it does is due to the limitations of its target userbase.

To elaborate: most AS users aren’t trained programmers and just don’t know (or care) about stuff like OOP, abstraction, top-down design, etc, etc. So there’s no way they’re going to think as far ahead as MVC, connections and all the other stuff that goes into professional GUI app design - heck, there’s an awful lot that don’t even grok “basic” concepts like “What are subroutines and why are they used?”(!) Therefore Studio has to use a model that’s accessible to such folk. I guess you could call it a “literal, reactive interface” or something if you wanted to put a label on it. Thus [e.g.] clicking a button fires a generic on-clicked event at the script - i.e. the event describes the literal action rather than its intent - and it’s left to the script to react to this event as it sees fit, figuring out where it came from and behaving appropriately.

Klunky? Definitely. But a good fit for the existing knowledge and thinking processes of your average AppleScripter, because (1) it takes relatively little abstract thought to grok such a simple and direct cause-effect relationship, and (2) it gives them an object, which is something they already know how to manipulate, that they can beat and hammer at with nothing more than the basic control structures (i.e. conditionals and loops) until they get it to do what they want it to.

To be honest, I don’t like Studio either, but that’s because I think its users would have been much better served by a HyperCard-style environment where there’s even less separation between GUI and code, so even less abstract design and thought required. I guess like anything Apple does these days it’s more a practical compromise than an ideal solution to the problem: long on pragmatism; bit short on vision. (But hey, you pays your money…;)

Also, everyone thinks “why not use keyword arguments?” when they first see PyObjC. Everyone is wrong, but it’s hard to articulate why.

errorWithString(myString, going = kToFile, to= filepath)

is that -errorWithString:going:to: and -errorWithString:to:going: are different selectors in Objective-C, whereas the order doesn’t matter in Python. Also, you can have selectors like –performSelector:withObject:withObject:. Keyword arguments are not the same thing as interspersing the parameters with the name.

The underscore scheme has some nice consequences. For instance, in Python the value of RWError.errorWithString_going_to_ is a callable object that does exactly what you would expect. It would be messier to get that object using the keyword scheme. It’s nice to have a one-to-one correspondence between methods and selectors.