|
On 20/01/2015 12:54, Takaaki Naganoya
wrote:
Whoa hoss. First, needs focus: you've loads of different issues there. ASOC issues are completely separate to library issues so should be dealt with separately, etc.
AppleScript Libraries will be made by ASOC scripts, not by pure AppleScript, I think.
We have not to build a house on a bog.
AppleScript libraries should be written in whatever's most
appropriate. For some tasks that's pure AS, for others it's ASOC.
Regardless, ASOC issues are still independent of library issues, and
need to be discussed separately. Small, focused bug reports and
feature requests have a much better chance of being addressed than
one giant amorphous "stuff is wrong".
For instance, you mention ASOC's lack of blocks support. Good point.
You should write up a Radar request that this be added. The proper
way to implement it would be for the user to pass a script object
containing an implicit/explicit `run` handler which ASOC then calls
as it would any AS handler:
script MyBlock
on run {arg1, arg2, ...}
...
end
end
While you're at it, you should also file a feature request that ASOC
allow AS objects to specify their own method signatures. Currently,
ASOC treats all parameters and results as ObjC objects (`id`), so
will crash when trying to invoke a method that [e.g.] takes a C
`int` as parameter or returns no result (`void`). e.g. Here's an
older but still valid discussion of this issue as it relates to
PyObjC:
https://jimmatthews.wordpress.com/2007/07/12/objcselector-and-objcsignature
A suitable AS equivalent to PyObjC's `@signature` would be for
script objects to include an optional `method signatures` property:
script MyClass
property parent : class "NSObject"
property method signatures : { ¬
insertObject_inEmployeesAtIndex_:"
v@:@I", ¬
removeObjectFromEmployeesAtIndex_:"v@:I" ¬
}
on insertObject_inEmployeesAtIndex_(obj, index)
...
end
on removeObjectFromEmployeesAtIndex_(index)
...
end
end
(Another option would be to ensure ASOC respects existing NSObject
methods that can be used to tell the ObjC runtime about method
names, signatures, etc. However, the `method signatures` approach is
simpler and easier to understand.)
Feel free to file a feature request on this as well. (I won't
because it doesn't affect me, but you're welcome to steal the
above.) When filing your blocks feature request, remember that block
script objects will need to support an optional `block signature`
property for specifying the correct signature as needed:
script MyBlock
property block signature : "v@:@I"
on run {someObj, someInt}
...
end
end
So I'd recommend you file the signatures feature request first, then
file the blocks feature request with a link to the first ticket
included in its notes (since full block support requires having
custom signature support first).
Second, no point talking about the state of older OS versions as those aren't going to change now.
Many people are afraid of Yosemite’s bug mountain (volcano). They still stay at OS X,10.9 or earlier.
So, a mixture of 10.10 and 10.9 is not minority, I feel.
You may care. Apple does not. Therefore irrelevant to discussion.
Third, the AS team has limited resources and even more limited support from above, so there's absolutely no point asking for grand sweeping rewrites of the AppleScript stack, Xcode, etc. because that ain't gonna happen.
I think, “How about AppleScript Libraries” theme seems below than others.
Whatever. A set of standard libraries gives all AS users measurable
bang for very little buck. That makes it both worthwhile *and*
achievable.
Xcode, Xcode, Xcode!
Xcode is the most important & severe matter.
Maybe for ASOC users. Not for Apple. Heck, the Swift and Xcode folks
are still struggling to get the Swift-Xcode integration working
correctly, and that job's one billionty times more important. The
AppleScript component doesn't have a modern incremental parser, a
standard debugging API, or any of the other basic essentials needed
to integrate it properly into Xcode a-la Swift. I see little point
talking grand plans such as Xcode/AS/OSA rewrites, because Apple
simply aren't interested. Focus on things that are realistically
achievable, then worry about how to maximize the chances of the AS
team getting it right.
Because even that is far from easy: e.g. take the six weeks I pissed
away last year desperately trying to get Sal &co. not to bollox
up _javascript_ for Automation. A fully working, fully supported JXA
attracting many thousands of new users would've re-energized and
regrown the entire scriptable app ecosystem, which also would've
kept AppleScript ticking over comfortably for many years to come.
Instead, the whole mess will most likely stay stillborn and stagnant
for the foreseeable future, or at least till Apple decides to wash
the whole mess away. Compared to that, your Xcode's AS woes are
*very* small beans indeed. By all means, file bug reports on it if
you're bored for something to do; just don't hold your breath for a
response, because your priorities are not Apple's priorities - or
even close.
Getting half-dozen nice standard AS libraries into 10.11 would provide significant benefit to all AS users at little cost to the AS team themselves.
I think, they should *not* make AppleScript Libraries by themselves. Because their sense is far from admiration.
Their sample script has been a terrible dream. And they have a few resources.
They should gather opinion from scripters. And, they have to invite applications, like *you* or Shane Stanley or the other scripters to make Apple genuine Script Libraries.
Agreed. However, I'm not doing anything until/unless OO Chris gets
back to us, because without the AS team's cooperation we'll just be
wasting our time on them. And I've done way too much of that
already.
Regards,
has
|