ну да

вот это первый шаг к позднему связыванию

а потом Кей решил

а что если в рантайме ебануть)

ну подозреваю что как-то так и было

точнее как

хотя может это еще от симулы

надо почитать

Кей хотел язык который позволяет обновлять систему не выключая ее

"микросервисы"

может наоборот надо пойти

ну мол смотри

паскать - компилируемый язык

ты не можешь ничего в рантайме просто так подменить, максимум через какой-то медиатор который будет проксировать вызовы на нужную реализацию

даже взять ту же java

там у тебя типа есть late binding

но тебе все же нельзя просто взять и подменить объект-зависимость

максимум через промежуточную проксю которая будет проксировать сообщения другим объектам

точно так же и импорты модулей

импортировал - юзай

надо что-то другое - значит надо перезагрузить модули для которых надо подменить зависимости

или я не прав?

ну не совсем улавливаю

ну тип late binding это про диспетчиризацию

кому адресовать сообщение

в языках типа js, python, java...

ты не можешь взять и переодресовать все сообщения для foo на bar

"подменить" foo на bar что бы никто не заметил

что бы это сделать надо "перезагрузить" все модули/объекты которые юзают foo и новые инстансы уже будут юзать bar

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things.

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

> C++, of course, does early binding everywhere it can--up to the point of performing StaticDispatch as a default (you have to ask for DynamicDispatch with the "virtual" keyword when you want it. [and even that, as in many other languages like Java, is only single dynamic dispatch. If you want "late binding everywhere," you need a much more powerful dispatch system, e.g. CommonLispObjectSystem's generics]).

http://wiki.c2.com/?SmalltalkLateBinding

последняя ссылка оч интересная

как по мне

короч хз, из того что я пока для себя уяснил... разницы нет

подменяешь ты модули или подменяешь ты зависимости через фабрики/сервис локатор/контейнер зависимости

результат остается такой же

если у тебя есть модуль/объект который импортировал/заинджектил в себя зависимость

что бы ее подменить тебе надо реинициализировать все зависимые штуки

а это сводит на нет все различие

ну а late binding по хорошему - duck typing

так что когда у тебя есть модули - у тебя автоматически есть IoC

что-то очень похожее на сервис локатор

более того

у тебя еще и сегрегация интерфейсов модулей есть

import {foo, bar} from 'module';

@mkusher что думаешь?

еще думаю)

поясните мне за double dispatch. допустим иерархии A и B связываются через DD. правильно я понимаю, что double он потому что два раза происходит маршрутизация вызова: первый раз это от интерфейса к конкретному классу в иерархии A, а второй раз к конкретному методу из интерфейса B?

смысл названия хочу понять

именно так

Спасибо

хотя погоди

> правильно я понимаю, что double он потому что два раза происходит маршрутизация вызова тут правильно

а дальше - хз)

хотя походу ты прав

"К конкретному методу" я имею в виду к одному из набора однотипных методов

да да

Спасибо

https://www.cs.cmu.edu/~charlie/courses/15-214/2014-fall/slides/25-history-oo.pdf

вот еще интересная штука

symfony! chat I want symfony chat!

что-то очень похожее на сервис локатор

Да по сути это сервис локатор со всеми глобальными привязками к пространству имен

у тебя еще и сегрегация интерфейсов модулей есть

А что с сегрегацией?)

ERROR: S client not available

А что с сегрегацией?)

ну ты юзаешь только то из модуля что юзаешь. Хотя хз

а, нуу, может быть

окей, пусть так A: index glueWithB B: index вот в этом glueWithB, в случае модулей, мы прямо сделаем import B from "B" и там делаем нужную нам обертку

немного не понимаю что есть glue

фасад над модулями?

ну типа

или модуль выше

не, условно говоря A и B два модуля

в пыхе\жаве ж принято было бы A: index NeededDependency // here goes an interface B: index GlueForAandBImplementingInterface

эээээм

у тебя есть два модуля, должен быть третий

который их юзает

окей, да

ну то есть... никакого клея, просто модуль. То что внутри нас не интересует

ну мол как по мне если не придумывать клеи и т.д. и воспринимать просто как элементы декомпозиции - то проще воспринимать

есть например модуль "платежки" и есть модуль "заказы". И есть модуль "сделать заказ и оплатить"

не уверен что мне не нравится в этих пирамидках, хм

неявное управление зависимостями?)

хз

Проблема кажется будет с тем, что это будет стимулировать вносить изменения прямо в модуль, а не создавать маленький модуль и заворачивать

Т.е. ситуация как использование конкретных классов и ioc framework с autowire

Нет абстракций)

Т.е. ситуация как использование конкретных классов и ioc framework с autowire

1. удобно 2. и без autowire мало интерфейсов используют

ну то есть проблема не с тем что autowire поощряет что-то там

а в том что люди не понимаю зачем это надо)

Проблема не в autowire, а то что теперь интерфейсов нет совсем

это как "автокомплит поощряет неадекватные названия"

> а то что теперь интерфейсов нет совсем у меня есть и я оооочень активно юзаю autowire

Остались только конкретные классы

Так а в модулях тогда где они?

Сам модуль не интерфейс, это уже конкретная реализация