Есть один язык программирования с кучей фреймворков и функционала.
Есть другой язык с кучей библиотек и функционала.
В системе используется и тот и тот язык. И вот настала необходимость из одной части вызывать функционал другой части.
Напрямую это сделать нельзя. Надо как-то все запросы протащить через один мост. Вопрос — как расширять функционал этого моста не расширяя сам мост?
Самое первое что приходит в голову — сделать функцию типа
Call(const char* funcName, const char* args)
В обработчике парсить аргументы и вызывать то что нужно. По идее через это можно протащить вообще все вызовы. Узкое место в произвоительности — парсинг запросов.
Здравствуйте, Amon_RA, Вы писали:
A_R>Есть один язык программирования с кучей фреймворков и функционала. A_R>Есть другой язык с кучей библиотек и функционала.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Amon_RA, Вы писали:
A_R>>Может какие-то другие решения можно придумать? K>RPC/RMI/COM/DBUS или иной брокер?
Одна часть — кроссплатформенная, вторая часть — уже зависит от платформы. Поэтому собственно и разделение.
Здравствуйте, Amon_RA, Вы писали:
Pzz>>А можно озвучить, как эти два языка называются?
A_R>Одна часть — кроссплатформенная — на С++ A_R>Вторая часть — зависит от платформы. На маке это обж-с, на винде это шарп.
Так их же всех можно друг из друга напрямую звать.
Здравствуйте, Amon_RA, Вы писали:
Pzz>>Так их же всех можно друг из друга напрямую звать.
A_R>И кроссплатформенный код превратится в лапшу условных компиляций.
С чего бы?
Надо просто определиться, кто кого зовет, и сформулировать платформенно-независимый интерфейс в виде набора сишных (т.е., именно сишных, а не плюсовых) функций.
Здравствуйте, Pzz, Вы писали:
Pzz>Надо просто определиться, кто кого зовет, и сформулировать платформенно-независимый интерфейс в виде набора сишных (т.е., именно сишных, а не плюсовых) функций.
Пххх. Дак в том и вопрос был — как расширять, не расширяя. Понятно, что все через единый интерфейс общения протащить можно, но этот интерфейс неимоверно раздуется, если на каждый пук отдельную функцию заводить.
Здравствуйте, Amon_RA, Вы писали:
A_R>Пххх. Дак в том и вопрос был — как расширять, не расширяя. Понятно, что все через единый интерфейс общения протащить можно, но этот интерфейс неимоверно раздуется, если на каждый пук отдельную функцию заводить.
Самое первое что приходит в голову — сделать функцию типа
Call(const char* funcName, const char* args)
В обработчике парсить аргументы и вызывать то что нужно. По идее через это можно протащить вообще все вызовы. Узкое место в произвоительности — парсинг запросов.
Вот вместо того, чтобы протаскивать все вызовы через обработчик, я предлагаю проэкспортировать их напрямую. Содержательных функций от этого больше не станет, но не надо будет еще и развесистый парсер с диспетчером писать. Который по существу абсолютно ничего полезного не добавляет.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Amon_RA, Вы писали:
A_R>>Пххх. Дак в том и вопрос был — как расширять, не расширяя. Понятно, что все через единый интерфейс общения протащить можно, но этот интерфейс неимоверно раздуется, если на каждый пук отдельную функцию заводить.
Если пуков слишком много — надо пересмотреть интерфейс взаимодействия.
Pzz>
Самое первое что приходит в голову — сделать функцию типа
Pzz>Call(const char* funcName, const char* args)
Pzz>В обработчике парсить аргументы и вызывать то что нужно. По идее через это можно протащить вообще все вызовы. Узкое место в произвоительности — парсинг запросов.
Pzz>Вот вместо того, чтобы протаскивать все вызовы через обработчик, я предлагаю проэкспортировать их напрямую. Содержательных функций от этого больше не станет, но не надо будет еще и развесистый парсер с диспетчером писать. Который по существу абсолютно ничего полезного не добавляет.
Согласен что надо проэкспортировать.
Дополнительные преимущества экспорта —
1. интерфейс взаимодействия зафиксирован и задокументирован в отдельном месте.
2. Изменения интерфейса взаимодействия контролируется компилятором с обеих сторон.
A_R>Пххх. Дак в том и вопрос был — как расширять, не расширяя. Понятно, что все через единый интерфейс общения протащить можно, но этот интерфейс неимоверно раздуется,
Только так у вас хотя бы компиляторы что-нибудь проверять будетут, а "с const char* funcName", если это не давным давно устоявшийся API, я даже не представляю, как жить.
A_R>В обработчике парсить аргументы и вызывать то что нужно. По идее через это можно протащить вообще все вызовы. Узкое место в произвоительности — парсинг запросов. A_R>Может какие-то другие решения можно придумать?
Парсинг запросов — насколько это место критично? Оптимизировать нельзя? А так, можно передавать текстовые запросы и не париться. Полная интероперабильность.
Здравствуйте, Amon_RA, Вы писали:
A_R>Есть один язык программирования с кучей фреймворков и функционала. A_R>Есть другой язык с кучей библиотек и функционала.
A_R>В системе используется и тот и тот язык. И вот настала необходимость из одной части вызывать функционал другой части.
A_R>Напрямую это сделать нельзя. Надо как-то все запросы протащить через один мост. Вопрос — как расширять функционал этого моста не расширяя сам мост?
A_R>Самое первое что приходит в голову — сделать функцию типа
A_R>Call(const char* funcName, const char* args)
A_R>В обработчике парсить аргументы и вызывать то что нужно. По идее через это можно протащить вообще все вызовы. Узкое место в произвоительности — парсинг запросов.
A_R>Может какие-то другие решения можно придумать?
Как вариант — кэшировать результаты парсинга запросов, если это возможно.
Здравствуйте, Amon_RA, Вы писали:
A_R>Одна часть — кроссплатформенная — на С++ A_R>Вторая часть — зависит от платформы. На маке это обж-с, на винде это шарп.
