Уход от AppleScript через Ruby: rb-appscript или rubyosa?

Quoth kch:

Это хорошо, но теперь мне интересно как скриптовый мост сравнивается с яблоко. Думаю, у меня будет немного чтение, чтобы сделать.

SB опускает некоторые функции, найденные в AppleScript. Например, следующий скрипт перемещает все файлы с рабочего стола в папку Documents:

tell application "Finder"
   move every file of desktop to folder "Documents" of home
end tell

В SB класс SBElementArray сильно ограничивает вашу возможность применять одну команду к нескольким объектам, поэтому вам либо придется прибегать к низкоуровневому API или получить список отдельных ссылок на файлы и перемещать их по одной:

require 'osx/cocoa'; include OSX
require_framework 'ScriptingBridge'

finder = SBApplication.applicationWithBundleIdentifier('com.apple.finder')
destination = finder.home.folders.objectWithName('Documents')
finder.desktop.files.get.each do |f|
   f.moveTo_replacing_positionedAt_routingSuppressed(destination, nil, nil, nil)
end

В rb-appscript вы должны использовать тот же подход, что и AppleScript:

require 'appscript'; include Appscript

app("Finder").desktop.files.move(:to => app.home.folders["Documents"])

...

SB скрывает событие Apple механизм гораздо тяжелее, чем AppleScript. AppleScript может быть проблемой, чтобы понять, что из-за странного синтаксиса, склонности к конфликтам ключевых слов и тому подобного, но помимо этого он в основном представляет события Apple как есть. Единственная действительно значимая магия в AS - это «неявное получение». поведение, когда он оценивает буквальную ссылку, которая не появляется в качестве параметра команды. Самый большой грех AppleScript заключается в том, что его документация лучше не объясняет, как он на самом деле работает, но есть очень хорошая статья Уильяма Кука , которая проливает свет на то, что на самом деле происходит.

SB, с другой стороны, изо всех сил пытается притвориться, что это настоящий Cocoa API с поведением в стиле какао, поэтому накладывает большое количество магии. Результатом является что-то внешне привлекательное для разработчиков Какао, но как только эти абстракции начинают просачиваться - а абстракции неизменно случаются - вы совершенно не понимаете, что происходит. Например, SBElementArray утверждает, что является массивом - он даже является подклассом NSMutableArray - но когда вы действительно пытаетесь использовать его методы массива, половина из них работает, а половина - нет. Фактически, это вообще не настоящий массив; это оболочка вокруг неоцененного спецификатора объекта события Apple, сфальсифицированного, чтобы притвориться NSMutableArray. Поэтому, когда он делает что-то не-похожее на массив, вы в значительной степени стараетесь понять, почему. И, как упоминалось в №1, некоторые из этих толстых абстракций затрудняют доступ к стандартным функциям событий Apple внизу.

SB в первую очередь пытается быть хорошим Cocoa API, а не хорошим API событий Apple, и в итоге оказывается не очень хорош в этом.

Appscript, кстати, следует примеру AppleScript и использует противоположный подход: делать события Apple правильными , а затем позаботьтесь об адаптации основного языка. Вот почему некоторые люди предпочитают RubyOSA, а не rb-appscript; в то время как appscript - более эффективное решение, если вы Если исходить из сильно объектно-ориентированного фона, это будет очень странно. Это связано с тем, что события Apple используют парадигму, основанную на RPC-плюс-запросах, и любое сходство сценария приложения с ООП является чисто синтаксическим. Ближайшей аналогией была бы отправка XQueries через XML-RPC, и к этому нужно привыкнуть.

...

SB имеет тенденцию испытывать значительно больше проблем совместимости приложений, чем AppleScript.

Некоторые из этих проблем связаны с тем, что SB навязывает свои собственные идеи о том, как Apple event IPC должен работать поверх того, как он на самом деле работает. Например, SB создает набор [псевдо] прокси-классов, представляющих классы, определенные в словаре; затем он налагает различные ограничения на то, как вы можете взаимодействовать с этими объектами, в основном на основе классических объектно-ориентированных правил поведения.

Например, следующий сценарий получает имена всех подпапок папки Documents:

tell application "Finder"
   get name of every folder of entire contents of folder "Documents" of home
end tell

Если вы попробуете тот же подход в SB:

finder.home.folders.objectWithName('Documents').entireContents.folders.arrayByApplyingSelector(:name)

, он дойдет до метода #folders, а затем выдает ошибку, потому что тип Свойство «все содержимое» в словаре Finder объявлено как «ссылка». Поскольку в словаре нет «эталонного» класса с элементами «папка», SB не позволяет вам создавать этот конкретный запрос (если вы не хотите перейти к низкоуровневым API и использовать необработанные коды AE). Это совершенно законно в соответствии с правилами событий Apple, но не вписывается в более узкий набор правил, ориентированных на объектно-ориентированный подход, наложенный SB.

Другие ошибки возникают из-за того, что SB делает предположения о том, как скриптовые приложения будут реализовывать определенные команды и другие функции. Например:

tell application "iTunes"
   make new playlist with properties {name:"test 1"}
end tell

SB не делает ' t позволяет вам использовать любые ярлыки, предоставляемые iTunes (вы можете опустить ссылку на исходный объект, в котором вы хотите создать список воспроизведения, и в этом случае используется основной источник `` Библиотеки ''), поэтому давайте напишем это полностью для лучшее сравнение:

tell application "iTunes"
   make new playlist at source "Library" with properties {name:"test"}
end tell

В SB вы бы написали это как:

itunes = SBApplication.applicationWithBundleIdentifier('com.apple.itunes')

playlists = itunes.sources.objectAtIndex(0).playlists()
newplaylist = itunes.classForScriptingClass(:playlist).alloc().initWithProperties({:name => 'test'})
playlists.addObject(newplaylist)

Однако, когда вы запускаете его, он блокирует #addObject. В своей попытке превратить одиночную команду make в многострочное упражнение, SB предполагает, что параметр at всегда будет ссылкой формы конец of