Бриджинг (программирование) - Bridging (programming)

Эта статья о системах, позволяющих взаимодействовать компьютерным языкам. Для шаблона объектного программирования см. Образец моста. Для компьютерная сеть системы, см. Мостовое соединение (сеть).

В Информатика, мосты описывает системы, которые отображают поведение различных языки программирования чтобы они могли делиться общими ресурсами. Они часто используются, чтобы позволить "иностранным" языкам работать с родной платформой хоста библиотеки объектов, переводя данные и состояние по обе стороны моста. Преодоление контрастов с системами «встраивания», которые допускают ограниченное взаимодействие через черный ящик механизм, в котором разделение состояний ограничено или отсутствует.

Apple Inc. несколько раз активно использовал мосты, особенно в ранних версиях Mac OS X которые подключились к более старым "классическим" системам с помощью Углерод система, а также Ява. Microsoft с общеязыковая среда выполнения, представленный .NET Framework, с самого начала разрабатывался как многоязычный и позволял избежать необходимости в обширных мостовых решениях. Обе платформы недавно добавили новые мостовые системы для JavaScript, Apple ObjC-to-JS и Microsoft HTML Bridge.

Концепции

Функции, библиотеки и среды выполнения

Большинство языков программирования включают концепцию подпрограмма или функция, механизм, который позволяет инкапсулировать часто используемый код и повторно использовать его в программе. Например, программе, интенсивно использующей математику, может потребоваться выполнение квадратный корень вычисление различных чисел по всей программе, поэтому этот код может быть изолирован в sqrt (число) функция, которая «передает» число для вычисления квадратного корня и «возвращает» результат. Во многих случаях рассматриваемый код уже существует, либо реализован на оборудовании, либо как часть базового Операционная система программа работает внутри. В этих случаях sqrt функцию можно еще больше упростить, вызвав встроенный код.

Функции часто делятся на легко идентифицируемые группы схожих возможностей, например, математические функции или работу с текстовыми файлами. Функции часто собираются вместе в коллекции, известные как библиотеки которые поставляются с системой или, что чаще всего в прошлом, языком программирования. У каждого языка есть свой метод вызова функций, поэтому библиотеки, написанные для одного языка, могут не работать с другим; семантика для вызова функций в C отличается от Паскаль, поэтому обычно программы на C не могут вызывать библиотеки Паскаля и наоборот. Обычно используемое решение этой проблемы - выбрать один набор семантика вызова в качестве системы по умолчанию для платформы, а затем все языки программирования должны соответствовать этому стандарту.

Большинство компьютерных языков и платформ обычно добавляют функциональные возможности, которые не могут быть выражены в модели вызова / возврата функции. Вывоз мусора, например, выполняется на протяжении всего времени выполнения приложения. Такая функциональность фактически находится «вне» программы, она присутствует, но не выражается непосредственно в самой программе. Подобные функции обычно реализуются в постоянно растущих время выполнения системы, библиотеки, которые скомпилированы в программы, но не обязательно видимы в коде.

Общие библиотеки и общие среды выполнения

Вступление к общая библиотека системы существенно изменили модель построения традиционных программ. Раньше код библиотеки копировался непосредственно в программы с помощью "компоновщик "и фактически стал частью программы. динамическое связывание код библиотеки (обычно) существует только в одном месте, это предоставленный поставщиком файл в системе, который используется всеми приложениями. Ранние системы представляли много проблем, часто с точки зрения производительности, а разделяемые библиотеки были в значительной степени изолированы для определенных языков или платформ, в отличие от операционной системы в целом. Многие из этих проблем были решены в 1990-х годах, а к началу 2000-х большинство основных платформ перешли на разделяемые библиотеки в качестве основного интерфейса для всей системы.

Хотя такие системы решали проблему предоставления общих библиотек кода для новых приложений, эти системы обычно также добавляли свои собственные среды выполнения. Это означало, что язык, библиотека, а теперь и вся система часто были тесно связаны друг с другом. Например, под OpenStep вся операционная система была, по сути, Цель-C программа. Любые программы, работающие на нем, которые хотели бы использовать обширный набор объектов, предоставленный в OpenStep, должны были бы не только иметь возможность вызывать эти библиотеки с использованием семантики Obj-C, но также взаимодействовать со средой выполнения Obj-C для обеспечения базового контроля над приложением.

Напротив, Microsoft с .NET Framework изначально разрабатывался для поддержки нескольких языков. C #, C ++ и новая версия Visual Basic. Для этого MS изолировала библиотеки объектов и среду выполнения в Инфраструктура общего языка (CLI). Вместо компиляции программ прямо из исходный код в базовый формат времени выполнения, как и в случае с большинством языков, в рамках модели CLI все языки сначала компилируются в Общий промежуточный язык (CIL), который затем вызывает общеязыковая среда выполнения (CLR). Теоретически любой язык программирования может использовать систему CLI и объекты .NET.

Мосты

Хотя такие платформы, как OSX и .NET, позволяют адаптировать большинство языков программирования к системе времени выполнения платформы, но также бывает и то, что эти языки программирования часто имеют в виду целевую среду выполнения - Цель-C по существу требует среды выполнения Obj-C, тогда как C # делает то же самое для CLR. Если кто-то хочет использовать код C # в Obj-C или наоборот, он должен найти версию, написанную для использования другой среды выполнения, которой часто не существует.

Более распространенная версия этой проблемы касается использования языков, независимых от платформы, таких как Java, которые имеют свои собственные среды выполнения и библиотеки. Хотя можно создать компилятор Java, который вызывает базовую систему, например J #, такая система также не сможет взаимодействовать с другим кодом Java, если она тоже не была перекомпилирована. Доступ к коду в библиотеках Java может быть трудным или невозможным.

Подъем веб-браузер как своего рода виртуальная операционная система, обострила эту проблему. Современная парадигма «программирования» под HTML5 включает JavaScript (JS) язык Объектная модель документа как основная библиотека, а сам браузер как среда выполнения. Хотя можно было бы создать версию JS, работающую в среде CLR, но это в значительной степени нарушило бы цель языка, предназначенного в основном для работы с браузерами - если этот компилятор не может напрямую взаимодействовать с браузером, его использование не имеет особого смысла. .

В этих случаях, а также во многих подобных случаях возникает необходимость в системе, которая позволяет двум средам выполнения взаимодействовать друг с другом. Это известно как «мост» между средами выполнения.

Примеры

яблоко

Apple широко использовала мостовые технологии с самых первых усилий, которые привели к Mac OS X.

Когда Apple впервые приобрела NeXT, планировалось создать новую версию OpenStep, известную в то время как Рапсодия, с эмулятор известный как Blue Box, который запускал «классические» программы Mac OS. Это привело к значительному сопротивлению со стороны сообщества разработчиков, и Rhapsody была отменена.[1] Вместо этого OS X будет реализовывать многие из старых вызовов Mac OS поверх основных функций OpenStep, обеспечивая путь для плавного переноса существующих приложений.

Для этого Apple взяла полезный код с платформы OpenStep и повторно реализовала основные функции в библиотеке на чистом C, известной как Основной фундамент, или сокращенно CF. Библиотеки OpenStep, вызывающие базовый код CF, стали Какао API, а новые библиотеки C, подобные Mac, стали Углеродный API. Поскольку стороны C и Obj-C системы должны были совместно использовать данные, а данные на стороне Obj-C обычно хранились в объектах (в отличие от базовых типов), преобразование в CF и из CF могло быть дорогостоящим. Apple не желала платить штраф за производительность, поэтому они внедрили схему, известную как «бесплатный мост», чтобы уменьшить или устранить эту проблему.[2]

В то время Java становилась основным игроком в мире программирования, и Apple также предоставила решение Java-моста, которое было разработано для WebObjects Платформа. Это было более классическое мостовое решение, при котором прямые преобразования между типами Java и OpenStep / CF выполнялись в коде, где это необходимо. В рамках Carbon программа, использующая CFStrings, использовала тот же код, что и приложение Какао, использующее NSString, и эти два элемента можно было соединить бесплатно. С помощью моста Java CFStrings вместо этого были преобразованы в собственные объекты String Java, что потребовало дополнительной работы, но сделало перенос практически невидимым.[3] Другие разработчики широко использовали аналогичные технологии для обеспечения поддержки других языков, включая систему «пиринга», позволяющую коду Obj-C вызывать код .NET под Мононуклеоз.[4]

Поскольку потребность в этих решениях для переноса уменьшилась, и Carbon, и Java Bridge были объявлены устаревшими и в конечном итоге удалены из более поздних выпусков системы.[5][6] Поддержка Java была перенесена на использование Собственный интерфейс Java (JNI), стандарт из мира Java, позволяющий Java взаимодействовать с кодом на основе C. В OSX JNI позволял использовать код Obj-C с некоторыми трудностями.[7]

Примерно в 2012 году Apple продолжила обширную работу над WebKit привело к внедрению новой технологии мостов, которая позволяет JavaScript программный код для вызова среды выполнения Obj-C / Cocoa, и наоборот. Это позволяет автоматизировать браузер с использованием Obj-C или, альтернативно, автоматизировать приложения Какао с использованием JavaScript. Первоначально часть Веб-браузер Safari, в 2013 году код стал частью новой OSX 10.9.[8]

Microsoft

Хотя есть несколько примеров использования моста в прошлом, система CLI Microsoft была предназначена для поддержки языков поверх системы .NET, а не для работы в собственных средах выполнения и мостов. Это привело к тому, что в системе CLI был реализован ряд новых языков, часто включающих в свое имя решётку (#) или «Iron». Увидеть Список языков интерфейса командной строки для более полного набора примеров. Эта концепция рассматривалась как пример MS обнять, протянуть и погасить поведение, поскольку он создавал Java-подобные языки (C # и J # например), которые не работали с другим кодом Java или использовали их библиотеки.

Тем не менее, «классическая» экосистема Windows включала значительный объем кода, который потребовался бы для использования в мире .NET, и для этой роли MS представила хорошо поддерживаемую мостовую систему. Система включает в себя множество утилит и языковых функций, упрощающих использование кода Windows или Visual Basic в системе .NET.[9] или наоборот.[10]

Microsoft также представила технологию моста JavaScript для Silverlight, HTML-мост. Мост предоставляет типы JS коду .NET, типы .NET - коду JS, а также управляет памятью и безопасностью доступа между ними.[11][12]

Другие примеры

Подобные технологии моста, часто с JavaScript на одной стороне, распространены на различных платформах. Одним из примеров является мост JS для ОС Android написано в качестве примера.[13]

Этот термин также иногда используется для описания объектно-реляционное отображение системы, которые устраняют разрыв между SQL мир баз данных и современные языки объектного программирования.

использованная литература

  1. ^ Дэйв Винер, "Рапсодия отменена", 12 мая 1998 г.
  2. ^ «Типы бесплатного моста», Apple, 19 сентября 2012 г.
  3. ^ «Использование Java Bridge», Яблоко
  4. ^ "Мостик"
  5. ^ Эндрю Юлл, «Apple сбрасывает мост между какао и ява», OSNews, 10 июля 2005 г.
  6. ^ «Износ углеродного ядра», Apple, 23 июля 2013 г.
  7. ^ «Техническое примечание TN2147: Разработка JNI в Mac OS X», Apple, 14 июля 2011 г.
  8. ^ Найджел Брук, «Новый мост Apple Objective-C в JavaScript», 14 мая 2013
  9. ^ Джейсон Кларк, «Вызов управляемого метода .NET из собственного кода», Журнал MSDN
  10. ^ «Вызов управляемого метода .NET из собственного кода», Microsoft
  11. ^ «HTML Bridge: взаимодействие между HTML и управляемым кодом», Microsoft
  12. ^ «Использование HTML-моста», Microsoft
  13. ^ «Разработка под Android: пример JavaScript Bridge - полное объяснение!» В архиве 29 июля 2013 г. Wayback Machine, граф объекта, 16 мая 2012 г.