5 ms·
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.in
by nsfmc 12y ago
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.
- bobbyi_settv 12y ago> why not use objs for named args? Because then there is no way of conveying the order of the parameters. In this case, it's ambiguous whether the method we are calling is colorWithRedGreenBlueAlpha, colorWithGreenBlueRedAlpha, etc.
- Zelphyr 12y agoOrder doesn't matter in the above example. In the method body you'd reference arguments[0].green when you wanted green.