The thing i'm not totally sold on is that for arg-free alloc/inits, you can forego 'calling' those methods at all so you get code like `task = $.NSTask.alloc.init;` but sometimes you have code like `ObjC.super(this).init;`. So although you're actually initializing a new object, casually glancing through the code makes it seem that you're actually just accessing a property on NSClassName. Jstalk/cocoascript i think get this right with `NSWhatever.alloc().init()`.

Still, it's a bit weird and it makes me think that the poor folks working on this didn't know what the swift folks were doing because if they had, i suspect that the cocoa-bridged syntax would feel even more natively javascripty than it does right now rather than what's here. For comparison

    // in swift
    var color = UIColor(red: 0.61, green: .71, blue: .23, alpha: .8)

    // in js for automation
    var color = $.UIColor.colorWithRedGreenBlueAlpha(.61, .71, .23, .8);
    
    // but why not use objs for named args?
    var color = $.UIColor({red: 0.61, green: .71, blue: .23, alpha: .8})
    

Of the two, the swift feels the most js-native to me because you can easily hallucinate the {}s from the third example. But even if you're creating a js bridge and you're apple, why even force people to deal with alloc/init anymore? Even the registerSubclass syntax feels like a concession

Don't get me wrong, I think it's great that we're getting better applescript support via js, but it's definitely an area where the implementation feels like a step back from cocoascript and jstalk, at least with both of those the syntax highlighted when you were engaging in nonidiomatic behavior but at least both tried their best to paper over it.

What should have been a lightweight approach actually feels more heavyweight than writing equivalent code in swift instead, which makes me sad because i like js and i would have really liked for this to have been more approachable.