[эволюция] Метапрограммирование

Это обычная модульность. Метапрограммирование зде не причем.

> Это обычная модульность. Метапрограммирование зде не причем.

Т.е. Лучше нарисовать «умный нарезчик исходника» чем транслятор с одного языка в другой?

Ну, это линковка самая обычная, как ты описываешь. А главное — зачем? Ежели система корпоративная, то веб интерфейс, даже и выдумывать ничего не смей.

Если по теме, то посмотри эрланговский OTP, может быть почерпнешь хороших идей.

> Лучше нарисовать «умный нарезчик исходника» чем транслятор с одного языка в другой?

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

> то веб интерфейс, даже и выдумывать ничего не смей.

Я ж написал, это не моя идея, а поставленная мне задача.

> Лучше правильно спроектировать программу, чтобы модули цепляли друг друга только там, где необходимо.

Косяк в том, что это что-то вроде протосервиса. Т.е. платформа для построения других документооборотов и в перспективе опенсорсная, по типу salesforge. Грубо говоря открыл ты свой стартап - денежку за аккаунт заплатил, натаскал себе в дашборд модулей взависимости от направления, прилепил лого - и всё документооборот у тебя есть (причём с пиринговыми замашками). Или допустим занимаешься ты чем-нибудь сильно специфичным и тебе нужно создать новый модуль - ты просто вешаешь объявление типа «надо сделать табличку для подсчёта такой-то мутотени, с меня сотни нефти». И какой нибудь фрилансер, создаёт новый модуль под твои нужды, ты пробуешь его, аппрувишь, отправляешь сотни нефти, фрилансер получает сотни-процент+модуль на продажу/или форк и продажу. Как всю эту байду клиенту выгрузить?

Принципы построения системы, основанной на плагинах, тоже известны, и они как раз из области обычной программной модульности, а не метапрограммирования. Система собирается из независимых модулей, каждый из которых использует другие через четко определенные API. Определение этих API и есть основная сложность, но метапрограммирование в этом не помогает.

Как всю эту байду клиенту выгрузить?

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

>Косяк в том, что это что-то вроде протосервиса.

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

Точно! Есть такой практический пример, даже - ТПК РАБИС-НП. В зависимости от ролей, пользователю доступны разные таски в его АРМе.

> Принципы построения системы, основанной на плагинах

Блин... а про плагины то я и не того... определённо пора спать.

Не понял вопроса.

Это был риторический вопрос. Имелось ввиду, что как-то всё это надо переформировывать по нуждам а не выгружать каждому кухонный комбайн. А вот в эклипсу да. В неё надо глянуть.

>ТПК РАБИС-НП

Не поминай РАБИС-НП всуе! А то ведь настанет!

Ты одессит, Мишка, а это значит, Что не страшны тебе ни горе, ни беда. Ведь ты моряк, Мишка, моряк не плачет И не теряет бодрость духа никогда!

Прорвёмся.

А и не выгружают каждому кухонный комбайн. Размещают одну клиентскую часть ПО на общедоступном ресурсе, и все. Если пользователей много, разделяют их на группы - для каждой группы свой общедоступный ресурс с клиентской частью, удобно расположенный.

Пользователи запускают один бинарник, возможно из собственных рабочих директорий. В зависимости от ролей пользователю доступны или недоступны различные АРМы, каждый из которых содержит определенный набор базовых возможностей.

Такой подход широко используется.

>А вот в эклипсу да. В неё надо глянуть.

В эклипсе используется OSGi. У нее слишком сложная спецификация, и под яву опять же заточено. Тогда можно посмотреть и на NetBeans, у него своя плагинная архитектура, и ЕМНИП, по другим принципам построенная.

CORBA? Но тоже слишком сложно.

Тебе нужно просто делать систему с веб-интерфейсом и строить интерфейс на основе ролей. Советы насчет модульностей ИМХО мимо кассы, так ка модульность для корпоративного софта весьма условная субстанция, так как на нижнем уровне практически всегда РСУБД, где все сущности из разных модулей повязаны ассоциациями. Что бы узреть что есть истинная модульнсть можно на сервис-ориентированной архитектуре, когда отдельный модуль (сервис) реально оторван от других модулей. Сразу появляется гемор с консистентностью данных и эффективной выборкой данных (к примеру по таблицам из разных БД эффективно сделать джойн нельзя).

1) Метапрограммирование тут ни при чём.

2) Метапрограммирование означает признание своего поражения.

тебя VSL покусал?

> Метапрограммирование означает признание своего поражения.

Не согласен. Хотя может тупо не доконца вкурил сей термин, но из вариантов

1) UML-диаграмма (а это в моей ситуации неизбежное зло) + кодер

2) Сценарий + кодогенератор

Я бы выбрал второе.

> тебя VSL покусал?

Нет вроде, а какое это к нему отношение имеет? Если относительно самого термина, то ниразу не VSL, поскольку он утверждал, а я спрашиваю и не особо фанатею от этого способа, просто крутится в мозгу мысль как сделать по уму, а сам себе изложить её не могу (прям ментальное ощущение), чувство такое, что всё можно аккуратно разложить по полочкам, привлечь 2-3 толковых кодеров и сделать нормальный проект, чем с кучей шлангов строить блотварь с применением квадратно-гнездовых методов с периодическим озвиздюливанием, чтоб не расслаблялись.

Я бы выбрал второе.

А я бы выбрал язык более высокого уровня. Не нуждающийся в костылях.