|
Владимир Лось попросил выложить наш с ним диалог на форум (сам он, видимо, в ближайшее время здесь не будет). Что я и делаю, немножко его подурезав...
[00:41:32] <wlad_los@jabber.ru> Если в языкв водятся каналы, то экспортированным функциям(процедурам) необходимо запретить к переменным модуля!
[00:42:03] <wlad_los@jabber.ru> Обращение к неэкспортированным переменным модуля
[00:42:56] <ilya.ermakov> Да я бы, по большому счёту, вообще позапрещал эти переменные модуля...
Проблема только в том, что сейчас они служат для динам. связей архитектурного типа (хуки, директории). Но если в язык ввести спец. средства для таких связей, то переменные глобальные можно почикать.
[00:44:12] <wlad_los@jabber.ru> Если внешние сущности обращаются к экспортированным процедурам, то это ни с каким "изменением состояния" модуля связываться не должно!
[00:44:42] <wlad_los@jabber.ru> Всё "изменения состояния" ТОЛЬКО черезобращения через КАНАЛЫ!
[00:46:10] <wlad_los@jabber.ru> Функции и процедуры -лишь нечто, группирующее последовательности действий и "обзывание" некоей функциональности
[00:46:18] <ilya.ermakov> разумно...
[00:48:29] <wlad_los@jabber.ru> Вызов функции - разовое действие, "транзакционное" и "одномоментное"
Работа через канал - "общение", растянутое по времени, с ВОЗМОЖНЫМ ВЗАИМНЫМ ИЗМЕНЕНИЕМ СОСТОЯНИЙ сторон
[00:51:57] <wlad_los@jabber.ru> Но, отсюда - вызов функции (при оговоренных выше условиях) - есть изменение НЕ СОСТОЯНИЯ сущности, которой функция "принадлежит"(в которой "описана"), а - С_В_О_Е_Г_О!!!!!!!!!!!!!!!!
То есть функция - предоставление услуги "занть как"поступить с "пришедшей", запросившей услугу (функциональность) сущностью!!!!
Теперь вопрос: ТАК ЧТО ЖЕ ТАКОЕ И_Н_Т_Е_Р_Ф_Е_Й_С?:о))))))
[00:53:11] <wlad_los@jabber.ru> Мы просто возвращаемся к тому, с чего первоначально начали классики - к АТД
[00:53:41] <wlad_los@jabber.ru> ... с добавлением формализации ПРОЦЕССА ОБМЕНА - с каналами!
[00:53:56] <ilya.ermakov> CLU?
Да, тут надо как-то провести различие между статической и динамической структурой программы. Вообще говоря, в современном программировании модуль ведь - это уже не модуль выполняющейся системы. Это скорее контейнер, описывающий детали, из которых конструируется в динамике система.
[00:56:02] <wlad_los@jabber.ru> Просто на уровне компилятора проводить анализ и ЗАПРЕЩАТЬ ОБРАЩЕНИЕ из эксопртированных функций к каким-либо переменным модуля!!!
ТОЛЬКО к тому, что пришло в аргументах!!!
[01:01:55] <wlad_los@jabber.ru> Всё дело в том, что я кажется понял, чем обеспокеон народ и почему с нами спорит за таблицы виртуальных функций!
[01:03:02] <wlad_los@jabber.ru> Они путают ОПИСАНИЕ (формальное!) "интерфейса" с описанием "НАМЕРЕНИЙ" его реализации в виде списка виртуальных функций!!!
А это - СОВЕРШЕННО РАЗНЫЕ вещи!!!
[01:03:22] <ilya.ermakov> КОНЕЧНО!
[01:04:02] <wlad_los@jabber.ru> Тем более, что ставшее традиционным задание "интерфейса" НЕ предусматривает того, о чём я уже долгое время толдычу: формализации актов обмена и изменения состояния!
[01:04:06] <ilya.ermakov> Интерфейс - это, вообще говоря, техническая точка доступа к объекту.
А то, какие сообщения и по какому протоколу он обрабатывает - это логика, содержательная часть.
[01:04:40] <wlad_los@jabber.ru> ПРАВИЛЬНО! Но логика НИЧЕМ не описывается сейчас на уровне программы!
[01:04:52] <wlad_los@jabber.ru> только - в доках!
[01:05:25] <ilya.ermakov> ну да. а нужно.
[01:06:07] <wlad_los@jabber.ru> А описание набора функций - сваливание в кучу того, как реализовывается интерфейс и что ВОЗМОЖНО будет вызвано! Но переходы в общении отсюда НЕ выводятся! Иногда только можно догадаться из названий методов! :о)))
[01:07:14] <wlad_los@jabber.ru> Кстати и отсюда (из непонимание) растут ноги часто встречающегося неправильного проектирования: два крйних случая: все функции сваливаются водин класс: либо интерфейс состоит из одной функции!!!
[01:11:18] <wlad_los@jabber.ru> А просто потому, что народ, с одной стороны привык (и - ИСКЛЮЧИТЕЛЬНО ПРАВИЛЬНО ПРИВЫК!!!) со времён фортрана, К НАБОРАМ функций В БИБЛИОТЕКАХ. И ПЕРЕНЁС это понимание на ОБЪЕКТЫ! А объекты - НЕ библиотеки!!! Объекты ДОЛЖНЫ быть АКТИВНЫМИ - в смысле обеспечения функциональности через активности, которые "прослушивают" СВОИ каналы! Именноэто -законченное и ПОЛНОЕ конечное движение ООП! А функции здесь - РЕАЛИЗАЦИИ обработки запосов по каналам. Вотэта связка и была сделана через их виртуализацию через таблицы виртуальныхфункций. Но это - ЧАСТНОЕ решение! ОГРАНИЧИВАЮЩЕЕ!
[01:12:01] <ilya.ermakov> !
[01:13:04] <wlad_los@jabber.ru> Функции достигают своей исключительной мощи ТОЛЬКО через свою ПОЛНУЮ "ЧИСТОТУ"(stateless), а объекты - чрезе изменение своегосостояния ТОЛЬКО через каналы!
[01:13:35] <ilya.ermakov> Верно...
[01:13:40] <wlad_los@jabber.ru> Так что же такое - КЛАСС тогда?
[01:13:52] <wlad_los@jabber.ru> :о)
[01:14:11] <wlad_los@jabber.ru> Мы же "отсоединяем" функции - ЧТО остаётся? :о)
[01:14:39] <wlad_los@jabber.ru> отсоединяем-от объектов
[01:15:03] <wlad_los@jabber.ru> Не делаем их "реализаторам" (ЯВНО!) "интерфейсов класса"
[01:15:13] <wlad_los@jabber.ru> Так что остаётся?
[01:15:47] <wlad_los@jabber.ru> В плане "определения" классов и "интерфейсов"?
[01:16:54] <ilya.ermakov> Ну, класс - это способность занимать определённое место в логике какой-то надсистемы. Т.е. играть роль.
[01:19:49] <wlad_los@jabber.ru> Но что такое РОЛЬ?Это - НЕ "набор" функций! "Играть роль" - это ДЕЙСТВИЕ, последовательность прохождения состояний в ответ на внешние события. Простым перечислением функций в "интефейсе" это НЕ описывается!!!
Так ЧТО НУЖНО СДЕЛАТЬ, ЧТО БЫ О_П_И_С_А_Т_Ь такой класс, если мы функции выкинули из"интерфейса"?:о))))
Ну-же, Илья!!! Осталось сделать одно звено в цепочке размышлений и логического вывода! :о)))
|
Вход
FAQ
Поиск
).
