L>Connection, в голове любого программиста, это соединение по какому-нибудь протоколу, которое умеет send/recv/close/shutdown. Код, который знает детали протокола обмена обычно вызывает эти методы, обмениваясь данными с удаленным хостом. Не понимаю как это "не нужно управлять".
Очень просто — Connection'ом управляет компонент который подключен к IData.
AC>>Достаточно просто, упаковать все составляющие компоненты в сборку, и можно работать с сервером как с монолитной, единственной сущностью. L>А зачем тогда все делается на компонентах?
Чтобы было возможно собрать сервер другой конфигурации, при этом не написав ни строчки кода.
L>Ну в статье идет речь о статических и динамических связях между компонентами, в разделе "управление памятью". Мне кажется делить связи по типам — излишнее усложнение.
Не, статическим и динамическими бывают компоненты. Первые это как-бы "скелет", они существуют всё время работы приложения(как например singleton'ы в ООП), вторые создаются по необходимости во время работы приложения.
AC>>В КОП используется другой механизм, чтобы сделать один компонент доступным другому, необходимо соединить(подключить) их интерфейсы. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Подключение/отключение интерфейсов это собственно и есть процесс "юзанья готового".
AC>>Непосредственно ЯП не поддерживается, но может быть реализована, например в виде интерфейса IComponentInfo. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Интерфейс IComponentInfo и его реализация, например могут быть унаследованы от прототипа Component(как в Java стандартные методы наследуются от класса Object).
AC>>Управление ресурсами (кроме памяти) по идее должно выполняется компонентами, ответственными за эти ресурсы. Освобождение ресурсов в таких компонентах может выполнятся в деконструкторе, автоматически вызываемом при разрушении компонента. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Деконструктор можно не использовать, если среда выполнения самостоятельно подчищает за вами(но это не очень хороший стиль).
AC>>Без проблем реализуется: один из компонентов — общая шина. L>Я программист, я не хочу ничего писать, я хочу юзать готовое!
Ни каких проблем*.
L>Я имел ввиду IDispatch.
Нет такое не возможно(из соображений безопасности) и не нужно. Тип интерфейса всегда должен быть известен на этапе компиляции.
AC>>Хочу сделать многокрасочность как в Go: каждый вызов функции в новом потоке. L>Это что-то странное, AFAIK, go так не работает. Там есть пулл потоков, но методы по дефолту не пушатся в пулл потоков, это не эффективно же!
(погорячился, "как в" следует читать "на подобии")
Да, в Go нужно указывать что вы желаете запустить функцию в отдельном потоке. Здесь нужно будет указывать что вы желаете подождать завершения функции, т.е. по умолчанию функции будут вызываться в отдельном потоке(будет ли это действительно так решает компилятор(например, если функция "лёгкая", незачем для неё создавать отдельный поток) и рантайм(например, если в пуле отсутствуют свободные потоки, выполнится в контексте вызывающего)).
AC>>Да, COM хорошая штука, но он бинарный и он сложен в использовании. L>Так у вас тоже не просто все. COM компоненты гораздо проще писать на .net например. И даже на С++ в студии, с использованием визардов и библиотеки ATL тоже не сказать что очень сложно. Но, по крайней мере COM существует в реальности. Поддерживается инструментами разработки. Многие продукты умеют работать как COM-сервер, например тот же MS Word.
Москва не сразу строилась.
L>Поэтому, имеет смысл либо использовать COM, либо, обеспечить interop с ним.
В первую очередь я хочу сделать "interop" с Java.
*В случае если MatWorks (или другой разработчик) выпустит соответствующий фреймворк
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[22]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexRK, Вы писали:
V>>Строй семантику как угодно. Например, ты можешь протянуть сигнал об ошибке на самый верх и реагировать на нее сразу, не дожидаясь обработки ошибки от нижних слоев. Эффект похож на достигаемый через исключения с одним отличием — детерминированность. Ведь подобная ошибка — это такой же "очередной" сигнал, а не "внеочередной", как исключения в менйстриме. Т.е. с одной стороны — такая же детерминированность как при пользовании кодами возвратов, с другой стороны — точно так же можно огранизовать топологию распространения сигнала ошибки сквозь уровни иерархий, как в механизме исключений.
ARK>Да, это все верно. Главное, чтобы работа с этими детерминированными линиями ошибки не слишком засоряла основной функционал (этого как раз пытаются обычно достичь с помощью исключений).
Обработка отдельного пина — это либо лямбда, либо вообще отдельный метод. Так что, никакого засорения "основного функционала" при обработке ошибок.
V>>Не забудешь, ты же его не опрашиваешь, он пришлет тебе в стиле push оповещение.
ARK>Ну на самом-то деле все равно где-то будет программный код — в описании функционала выходов. И в этом коде программист как раз должен "дергать" выходы другого компонента, возможно, при особых условиях.
Компонент "дергает" свои выходные пины и понятия не имеет, что затем происходит.
ARK>Например. Есть компонент с двумя входами — A и B, одним выходом — C. Значение C = A / B. ARK>Да, я могу запрограммировать C как "return (B != 0) ? (A / B) : 0", но я этого не хочу. Я хочу, чтобы C имел смысл только в случае, когда B != 0.
Я же уже говорил, ограничения на типы данных в реакцтивном программировании ничем не отличаются от ограничений на типы данных для "обычного" ФП или ООП. Предложи вариант решения твоей задачки для ФП или ООП и это решение так же подойдёт для реактивного программирования.
ARK>Таким образом, мы не можем подключить наш компонент как попало.
Это ты немного передёргиваешь с подбором слов для озвучивания своей мысли. Следуя той же логике, мы сейчас можем вызвать метод div(A, B) в любом языке из мейнстрима "как попало", потому можем подать на B ноль.
Но на этом прямо сейчас стоит вся индустрия... ))
ARK>Например, мы не имеем права поставить на вход B заглушку, подающую константу "0" (это не имеющий смысла пример, вырожденный случай) — программа не должна скомпилироваться.
Современные компиляторы довольно сносно выполняют распространение констант, поэтому подача константы 0 не интересна ни разу. Ну да, некоторые компиляторы догадаются предупредить о делении на 0. Зато, если мы прочитали этот 0 из файла, то на сегодня только системы с зависимыми типами способны гарантировать, что проверка на 0 будет выполнена перед вызовом div(A, B).
V>>А если тебе нужны ограничения — то можно задать ограничение на запрет "висячего" состояния этого пина в компоненте-источнике. )) И тогда, чтобы намеренно проигнорировать этот пин, тебе придется явно подключить к нему каку-нить заглушку.
ARK>Но ограничения могут быть более комплексными, чем просто запрет висячего провода.
Э, нет. Это разные виды ограничений. Мы рассмотрели ограничения на данные, а я говорил об ограничениях на подключения, согласно которой, запрещается игнорировать помеченные выходные сигналы.
V>>Некоторые компоненты могут давать сигнал ошибки, некоторые — нет. Например, сумматор может давать признак переноса, и ты можешь считать его согласно своей логики за ошибку (потерю значения) или нет, если это счетчик фазы, например, тогда переполнение до фени.
ARK>А вдруг компонент не просто выдает опциональный сигнал ошибки, а требует, чтобы этот сигнал нельзя было проигнорировать?
Ну вот и запрети ему "висячий" выход.
ARK>Ну, что в самом низу, для верхнего программиста не так важно. Разница в том, что исключение все эти штуки делает за сценой, плюс его нельзя проигнорировать, в отличие от кодов ошибок.
Как это нельзя игнорировать?
try { blah_blah() } catch {}
Это полный аналог предлагаемого "осознаного" подключения заглушки-игнора к механизму сигнализации об ошибке.
ARK>Maybe — это достаточно простая вещь, хотя и очень полезная. Кстати, а какие еще примитивные типы вы предполагаете использовать?
Я предлагаю использовать сколь-угодно сложные непримитивные типы. Всех ограничений — это отделить графы вычислителей от графов данных.
ARK>Но ограничения могут быть в теории гораздо более комплексные, чем maybe... Например, затрагивающие сразу несколько пинов.
Возможно. Но тут как в любой задаче — формулируй цель, доказывай её целесообразность и затем находи решение. Если ты выдашь такие требования, то некий конечный язык вполне может эти требования реализовать.
ARK>Да, это верно и для обычного программирования. Просто как-то мне кажется, что на реактивно-компонентную модель они могут лечь более естественно. Превращаются в этакие правила совместимости компонентов. Как разъем HDMI нельзя воткнуть в DVI.
При наличии возможности определять пользовательские составные типы данных это решается обычной типизацией:
data HDMI { RGB rgb; ... }
data DVI { RGB rgb; ... }
ARK>Да, и все-таки интересно было бы услышать ваше мнение по поводу двух вопросов из прошлого моего поста:
ARK>Изменяемое состояние у вас предполагается в виде "устойчивых состояний системы"?
Суть желаемого ограничения на типы-данные сводится к следующему: мутабельный тип — это явная ячейка для хранения иммутабельного значения.
ARK>Или будет какой-то аналог полей-атрибутов из ООП (во что слабо верится)?
Почему слабо? ))
Наоборот, мне требуется контроллируемая мутабельность. Но для её достижения предлагается очень простое ограничение — мутабельные переменные могут быть либо локальными переменными, либо полями "вычислителей", где сами графы вычислителей иммутабельны. Поля данных всегда иммутабельны.
Итого, получившаяся схема становится карйне подозрительно похожа на Хаскелевскую, где через чистое ФП сначала строится иммутабельный "вычислитель", а затем на нём выполняются "зацикленные" вычисления через монаду IO. Т.е. я вижу приближение к одному и тому же с разных сторон. Вернее так, понимание проблематики ПО всё больше заставляет программистов смириться с тем, что "железячные" наработки в любом случае будут диктовать моду в ПО. Пример принципа работы программы на "новомодном" Хаскеле тому пример: построили схему --> подали ей даные.
ARK>"Есть еще вот такой момент. Мыслю с точки зрения обычного ООП. Например, мне нужна в моем компоненте работа с файлом. Значит я должен ввести кучу пинов, к которым подключаю компонент, работающий с файлами. Т.к. все пины только примитивных типов, то их будет куча для каждого мало-мальски сложного объекта. Нет ли тут проблемы?"
Я думаю, что ты упустил тот момент, что я ни в коем случае не настаивал на том, что данные должны быть исключительно примитивных типов. Т.е. вопрос сразу теряет смысл.
ARK>Т.е. вопрос в том, не возникнет ли чрезмерного количества пинов у сложных компонентов из-за отсутствия абстрагирующих сложность сущностей типа ООП-шных объектов?
Гы-гы... Я наоборот уверен, что в обычном ООП, при наличии дешевого механизма "декомпозиции на атомы", мы бы давно пришли к тому, что кол-во слоёв в средней программе было не 2-3, а порядка 10-20. То бишь, вся программа была бы составлена из наипростейших/наипримитивнейших компонент (с большим уровнем вложенности, если рассматривать подробности). Прямо сейчас при попытке построить подобный дизайн мы получаем болезненный штраф за сумашедшую итоговую косвенность вычислений, отсюда и растут ноги "жирных" компонент — это из-за необходимости держать под контролем уровень косвенности вычислений.
Re[23]: Заметка: Компонентная философия и реализация
Во-первых, традиционно — спасибо за развернутый ответ.
V>Я предлагаю использовать сколь-угодно сложные непримитивные типы. Всех ограничений — это отделить графы вычислителей от графов данных.
Речь про комплексные рекорды-структы, без методов?
А если хочется инкапсулировать какие-то секретные данные? Можно, конечно, сделать что-то типа — объявить такой рекорд "Р" вместе с компонентом "К" внутри некоторого общего модуля "М", за пределами которого поля рекорда "Р" не доступны, а работать с ним можно только через компонент "К".
V>Я ждал этого вопроса давно и отвечал на него "предупредительно": http://www.rsdn.ru/forum/philosophy/4959771.1
V>Наоборот, мне требуется контроллируемая мутабельность. Но для её достижения предлагается очень простое ограничение — мутабельные переменные могут быть либо локальными переменными, либо полями "вычислителей", где сами графы вычислителей иммутабельны. Поля данных всегда иммутабельны.
Да, я это помню. Но это немного не то. Вопрос был — где хранится состояние.
Я так понял, что состояние хранится во внешнем "процессоре". Хотя это вопрос философский, где что хранится, зависит от точки зрения.
Если требуется сделать, например, стек или список — то для хранения состояния (массива элементов) придется замыкать входы на выходы, как в вашем триггере? Чтобы при следующем дергании входа "Add" с выхода предварительно считалось текущее состояние?
Остальное в общем понятно.
Кстати, я довольно давно читал про разработку — Акторный Пролог. Идея там заложена та же самая, что и в вашем подходе. За исключением того, что в основе там не ЯП общего назначения, а логическое программирование. Правда, очень многое не продумано, а реализовано так вообще криво. Ну что поделать, академический проект.
Это реализация в компонентном стиле(поверх ООП) третьего примера из заметки Компонентная философия и реализация на ЯП Scala.
В этом примере используется небольшой рантайм, реализующий некоторые из возможностей описанных в заметке, в частности сборку из компонентов и интерфейсы, а также(в некоторой степени) управление жизненным циклом компонентов. Вышло это всё довольно криво и многобуквенное(ибо натянуто на ООП и ФП), но тем не менее это работает
Вот так выглядит код собирающий приложение(отладочные сборки закомментрованы):
Скрытый текст
//Create named components
object Building extends Component {def main(args:Array[String]){}
val name = MMap[String, Component]()
/*Build program*/
//View
name += ("frame" -> new Frame(name))
name += ("viewDraw" -> new ViewDraw(name, "IWidgets", name("frame")))
name += ("statusBar" -> new StatusBar(name, "IWidgets", name("frame")))
//Matrix
name += ("space" -> new Space(name))
name += ("camera" -> new Camera(name))
connect("ILayout", name("space"), name("camera"))
connect("IViewDraw", name("viewDraw"), name("camera"))
//Game
name += ("arena" -> new Arena(name))
connect("IViewSettings", name("viewDraw"), name("arena"))
name += ("joystick" -> new Joystick(name))
connect("IFrame",name("frame"),name("joystick"))
connect("IControl",name("space"),name("joystick"))
connect("IControl",name("camera"),name("joystick"))
name += ("targetGen" -> new TargetGen(name))
connect("ITargetGen",name("targetGen"),name("joystick"))
connect("ITracking",name("targetGen"),name("joystick"))
connect("ITracking",name("targetGen"),name("arena"))
name += ("observer" -> new Observer(name))
connect("IAvatarWatch",name("observer"),name("joystick"))
connect("ITargetWatch",name("observer"),name("targetGen"))
connect("IStatusBar",name("observer"),name("statusBar"))
// /*Build test game*/
// //View
// name += ("frame" -> new Frame(name))
// name += ("testViewDraw" -> new TestViewDraw(name, "IWidgets", name("frame")))
// //Matrix
// name += ("space" -> new Space(name))
// name += ("testCamera" -> new TestCamera(name))
// connect("ILayout", name("space"), name("testCamera"))
// connect("ITestViewDraw", name("testViewDraw"), name("testCamera"))
// //Game
// name += ("arena" -> new Arena(name))
// connect("IViewSettings", name("testViewDraw"), name("arena"))
// name += ("joystick" -> new Joystick(name))
// connect("IFrame",name("frame"),name("joystick"))
// connect("IControl",name("space"),name("joystick"))
// connect("IControl",name("testCamera"),name("joystick"))
// name += ("targetGen" -> new TargetGen(name))
// connect("ITargetGen",name("targetGen"),name("joystick"))
// connect("ITracking",name("targetGen"),name("joystick"))
// connect("ITracking",name("targetGen"),name("arena"))
// /*Build test matrix physics*/
// //Manager
// name += ("testManager" -> new TestManager(name))
// //View
// name += ("frame" -> new Frame(name))
// connect("IFrame",name("frame"),name("testManager"))
// name += ("testViewDraw" -> new TestViewDraw(name, "IWidgets", name("frame")))
// //Matrix
// name += ("space" -> new Space(name))
// connect("IControl",name("space"),name("testManager"))
// name += ("testCamera" -> new TestCamera(name))
// connect("IControl",name("testCamera"),name("testManager"))
// connect("ITestViewDraw", name("testViewDraw"), name("testCamera"))
// connect("ILayout", name("space"), name("testCamera"))
// //Objects
// name += ("obj1" -> new TestObj1(name))
// name += ("obj2" -> new TestObj2(name))
// /*Build test matrix texture*/
// //Manager
// name += ("testManager" -> new TestManager(name))
// //View
// name += ("frame" -> new Frame(name))
// connect("IFrame",name("frame"),name("testManager"))
// name += ("viewDraw" -> new ViewDraw(name, "IWidgets", name("frame")))
// connect("IViewSettings",name("viewDraw"),name("testManager"))
// //Matrix
// name += ("space" -> new Space(name))
// connect("IControl",name("space"),name("testManager"))
// name += ("camera" -> new Camera(name))
// connect("IControl",name("camera"),name("testManager"))
// connect("IViewDraw", name("viewDraw"), name("camera"))
// connect("ILayout", name("space"), name("camera"))
// //Objects
// name += ("obj1" -> new TestObj1(name))
// name += ("obj2" -> new TestObj2(name))
}
Мнения и конструктивная критика приветствуются!
PS: Если вы с чем-то не согласны, пожалуйста не ленитесь написать с чем именно. Интересно же!
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
AC>Мнения и конструктивная критика приветствуются!
Совсем-совсем ни каких мыслей?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
AC>read more>>>
Знаете, вот недавно сам пришел к выводу, что подобная технология, на мой взгляд — самый грамотный вариант программирования. Мне нравится наличие небольшого количества общих концепций и в целом последовательность.
Лично я бы дал возможность вкладывать компоненты друг в друга, как микросхемы.
И, наверное, запретил бы полностью динамическое создание/удаление компонентов.
Хотя со вторым вариантом возникает вопрос — как быть, если мы хотим, к примеру, создать "форму" по XML-описанию из файла? Или создать два экземпляра одной формы? В этом случае получается, что нам нужны stateless-компоненты, которые будут принимать состояние параметром и работать с ним. А в другом случае окажется, что удобнее работать с инкапсулированным внутри компонента состоянием. Иметь два типа компонентов на все случаи жизни как-то накладно, а что тут еще можно придумать, пока не знаю.
Плюс еще непонятно, в каком виде будет представляться это самое "внешнее состояние" — оно должно хранить всю иерархию состояний вложенных компонентов, причем их состав в каждом случае будет разным. Короче, в этом месте как-то сложновато.
Re[2]: Заметка: Компонентная философия и реализация
ARK>Лично я бы дал возможность вкладывать компоненты друг в друга, как микросхемы.
Я для этого планирую использовать сборки, они снаружи как компонент(т.е. работа с ними не чем не отличается от работы с компонентами), но внутри состоят из компонентов.
ARK>И, наверное, запретил бы полностью динамическое создание/удаление компонентов. ARK>Хотя со вторым вариантом возникает вопрос — как быть, если мы хотим, к примеру, создать "форму" по XML-описанию из файла? Или создать два экземпляра одной формы? В этом случае получается, что нам нужны stateless-компоненты, которые будут принимать состояние параметром и работать с ним. А в другом случае окажется, что удобнее работать с инкапсулированным внутри компонента состоянием. Иметь два типа компонентов на все случаи жизни как-то накладно, а что тут еще можно придумать, пока не знаю. ARK>Плюс еще непонятно, в каком виде будет представляться это самое "внешнее состояние" — оно должно хранить всю иерархию состояний вложенных компонентов, причем их состав в каждом случае будет разным. Короче, в этом месте как-то сложновато.
Зачем гадать? Вы можете запилить своё КОП с вложенностью и статическими компонентами, модифицировав существующий движок. Поиграть с ним и посмотреть что получится.
Я ,например, использовал этот движок в одном небольшом приложении, и нашел что не хватает хорошей, надёжной потоковой модели (~6/10 проблем, были проблемами с синхронизацией).
PS: В этой заметке я описал наиболее свежую модель парадигмы (если вы ещё не читали), в будущем планирую развивать проект в этом ключе.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
— а здесь: http://simulators.narod.ru/sedov.zip — архив с текстовым файлом, где автор сайта поделился древней фидошной перепиской с неким товарищем А. Седовом, который представил свою "машину теорий" — вычислительную среду на базе таблиц решений и фортоподобного языка. Интересное чтиво по поводу моделирования систем и современного ООП, КОП и прочего программирования.
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Рискну отметиться по своим разработкам.
Текстовые, графические, а у меня еще и табличное представление это лишь представление. Языки устаканятся в единый синтаксис. В синтксис не только как текстовое представление, а как выражение сущностей. Так проще понимать. Объединяться парадигмы фунциональные, императивные и прочие.. Из объектной парадигма станет субъектной, что объединит и все настоящие и будущие парадигмы являясь к тому же метаязыком формирующим понятия для манипулирования.
