Вообще понятия "внешнее поведение объекта" , "внутреннее поведение объекта" достаточно сложны. Лисков же всё просто определяла. Вот есть объект базового класса X, ссылка x. У него есть свойство F(x) , и есть какой-то код , работающий с этим объектом. Если мы хотим использовать наследников (Y), то для всех Y свойство F(y) должно быть валидным.

это определение просто, если есть непропитый скилл в математике)

А по теории типов?

Теория типов разве не изучается в курсе лямбда-исчисления?

Теория типов разве не изучается в курсе лямбда-исчисления?

Я от лямбд только экспрешоны в C# знаю

Я от лямбд только экспрешоны в C# знаю

Вот суперский курс https://www.youtube.com/watch?v=7BPQ-gpXKt4&list=PLlb7e2G7aSpRDR44HMNqDHYgrAOPp7QLr

вот получается, что ооп это когда функции вызываются через синтаксис точки, но я тут заметил, что в эрланге для этого используют двоеточия. значит ли это, что эрланг в два раза более ооп чем джава? и связано ли обозначение типов в хаскеле с этим (там два двоеточия)?

А тут предусмотрен бан тролей?

вот получается, что ооп это когда функции вызываются через синтаксис точки, но я тут заметил, что в эрланге для этого используют двоеточия. значит ли это, что эрланг в два раза более ооп чем джава? и связано ли обозначение типов в хаскеле с этим (там два двоеточия)?

на счет хаскеля не скажу - но эрланг да, в два раза более ооп чем джава)

хотя можно пойти в другую сторону - в C++ два двоеточия используются для вызова статических методов, что противоречит идее ООП. Так что количество точек не всегда говорит нам о "насколько длиннее ООП"

а если у нас гипотетически есть язык где можно вызывать функции и через : и через . то это значит что мы можем переключаться между двумя степенями ооп?

а в objective-c вообще нет точек

а если у нас гипотетически есть язык где можно вызывать функции и через : и через . то это значит что мы можем переключаться между двумя степенями ооп?

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

но ооп это синтаксис точки

но ооп это синтаксис точки

нет

ооп это нечто что родилось в голове Алана Кея и все там же сидит и никому не показывается

а все остальное - просто структурное програмирование

но ооп это синтаксис точки

посмотри смолтак) шутки ради)

я смотрел, там не через точку вызываются вроде

я смотрел, там не через точку вызываются вроде

да, через точку это симула и плюсы. А от них уже в джаву перекочевало

вот, ооп

вот, ооп

ну... если сделать разделение на объектно-ориентированное и ориентированное на сообщения - тогда соглашусь)

хорошая идея

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

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

ой сколько у нас таких обсуждений было

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

я думал все уже изучили это

тут не так давно Алан Кей лично пробегал и говорил что он под объектами имел ввиду

названия после которых можно писать точку и вызывать функции

тут не так давно Алан Кей лично пробегал и говорил что он под объектами имел ввиду

Но его не поняли и закидали точками.

Но его не поняли и закидали точками.

эт да)

Метод референсы в джаве через двоеточие, и через точку обращения есть, значит там 1.5 или 3 ооп?

Но его не поняли и закидали точками.

ты к слову его отсылки изучал?

Метод референсы в джаве через двоеточие, и через точку обращения есть, значит там 1.5 или 3 ооп?

хоть кто-то понимает

В пхп статические вызовы через 2 двоеточия. Это 4 ООП.

?

В пхп статические вызовы через 2 двоеточия. Это 4 ООП.

это 2 C++

или 3.14 C

ты к слову его отсылки изучал?

Нет. Я из того, что он говорил понял примерно половину.

Нет. Я из того, что он говорил понял примерно половину.

ну он в одном из комментариев уверенно так топит в сторону actor model)

То есть примерно половину точно НЕ понял, а про вторую вопрос открытый.

> "Simulating time" along with all other behavior allows for a much more understandable universe to be made, including eliminating race conditions in a much safer and more comprehensive way than (say) semaphores.

ну он в одном из комментариев уверенно так топит в сторону actor model)

Акторы это где все асинхронно и время доставки не гарантировано?

А что тут думают про грааль?

Акторы это где все асинхронно и время доставки не гарантировано?

почему тебе важно время доставки? Оно же все асинхронно и просто сообщениями обменивается

Вот суперский курс https://www.youtube.com/watch?v=7BPQ-gpXKt4&list=PLlb7e2G7aSpRDR44HMNqDHYgrAOPp7QLr

слушал его вживую, и правда крут

Акторы это где все асинхронно и время доставки не гарантировано?

ну мол, экторы это способ избавиться от времени... у тебя сами экторы решают когда они хотят сообщения принять. Мэйлбоксы и все такое

почему тебе важно время доставки? Оно же все асинхронно и просто сообщениями обменивается

Ну я помню какой-то видос смотрел. Там говорили, что акторы порождают другие акторы и кидаются сообщениями, которые могут доходить бесконечно долго.

могут доходить бесконечно долго, но тебе как эктора кинувшего сообщение это вообще не должно волновать

Естественно я нихрена не понял из этого видоса.

Т.е. акторы в rtos невозможно использовать?

Естественно я нихрена не понял из этого видоса.

представь себе систему из кучки процессов которые обмениваются через pub/sub сообщениями о том что они что-то сделали

Т.е. акторы в rtos невозможно использовать?

почему ты строишь такие выводы?

Метод референсы в джаве через двоеточие, и через точку обращения есть, значит там 1.5 или 3 ооп?

смотри, степень ооп определяется по количеству точек. obj.method (1 oop) obj:method, obj..method (2 oop) obj:.method, obj.:method, obj...method (3 oop) obj::method, obj:..method, obj.:.method, obj..:method, obj....method (4 oop) но дробным ооп не может быть. если в коде встречается одновременно несколько вариация ооп то у нас суперпозиция одной степени ооп с другой

Ну как минимум потому что тут вот начались истории о рекурсивных акторах, которые порождаются и обмениваются сообщениями, не волнуясь о времени их обработки.

Т.е. акторы в rtos невозможно использовать?

Нет, это значит что асинхронность это фундаментальное свойство математической модели акторов

Что бы это ни значило

смотри, степень ооп определяется по количеству точек. obj.method (1 oop) obj:method, obj..method (2 oop) obj:.method, obj.:method, obj...method (3 oop) obj::method, obj:..method, obj.:.method, obj..:method, obj....method (4 oop) но дробным ооп не может быть. если в коде встречается одновременно несколько вариация ооп то у нас суперпозиция одной степени ооп с другой

если мы с тобой определились про какое ооп мы говорим - то спор не имеет смысла. Какая бы не была степень ООП - это всеравно не то)

Что бы это ни значило

отсутствие data sharing между экторами)

ну или его минимизация)

если мы с тобой определились про какое ооп мы говорим - то спор не имеет смысла. Какая бы не была степень ООП - это всеравно не то)

то.. ты же придумал свое название для другого понятия

то.. ты же придумал свое название для другого понятия

давай накидывай чего поинтереснее, я верю ты можешь

?

?

Ну ты хорошо зашёл про точки.

Развивай успех

отсутствие data sharing между экторами)

И без IO.)

Вот кстати. Я чёт не помню, что там про сайд-эффекты говорили

Что бы это ни значило

ну короч, из того что он пишет я все больше убеждаюсь что самый ОО язык из нынеживущих это эрланг)

ERROR: S client not available

Вот кстати. Я чёт не помню, что там про сайд-эффекты говорили

а у тебя может система делать что-либо полезное без сайд эффектов? другое дело что их можно красиво изолировать

Нам нужны экторные монады

Нам нужны экторные монады

зачем?

Чтобы изолировать

Отправка сообщения это запись в майлбокс. Чем не IO, только очень быстрое? Или что-то упускаю?

Отправка сообщения это запись в майлбокс. Чем не IO, только очень быстрое? Или что-то упускаю?

ну вот я про то же.

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

Предлагаю сделать неделю солида, а то чет тихо

астрологи провозгласили неделю солида, количество срачей увеличилось вдвое

^ надо закрепить это сообщение)

Предлагаю сделать неделю солида, а то чет тихо

давай лучше обсудим вопрос который меня мучает последние 2 недели - есть ли смысл в выделении стольких типов кохижена? может быть в реальности нужно 3-4 варианта и хватит?

не знаю ни одного и ок живётся)

перечисляй

не знаю ни одного и ок живётся)

как же? а как же твой друг - случайный кохижен?)

как же? а как же твой друг - случайный кохижен?)

??

как же? а как же твой друг - случайный кохижен?)

теперь 1 знаю)

давай лучше обсудим вопрос который меня мучает последние 2 недели - есть ли смысл в выделении стольких типов кохижена? может быть в реальности нужно 3-4 варианта и хватит?

а какие еще есть? я рассматирваю связи как внутренние связи внутри модуля, и внешние связи между модулями

то есть 2

и то это кохижн и каплинг

виды кохижена (которые определяются вопросом "почему эти штуки вместе2) - случайный (рандом, утилиты) - логический (когда "логично" что оно вместе но это совсем разные штуки) - временной (штуки внутри модуля связывает только тот факт что мы вызываем их примерно в одно и то же время) - процедурный (штуки внутри модуля нужны для одного и того же алгоритма, хотя вне контекста алгоритма связи между ними нет) - информационный (все штуки в модуле работают с одними и теми же данными) - последовательный (все штуки в модуле являются частью пайплайна И! принимают на вход то что вернул предыдущий этап этого пайплайна) - функциональная (благодать и SRP)

виды кохижена (которые определяются вопросом "почему эти штуки вместе2) - случайный (рандом, утилиты) - логический (когда "логично" что оно вместе но это совсем разные штуки) - временной (штуки внутри модуля связывает только тот факт что мы вызываем их примерно в одно и то же время) - процедурный (штуки внутри модуля нужны для одного и того же алгоритма, хотя вне контекста алгоритма связи между ними нет) - информационный (все штуки в модуле работают с одними и теми же данными) - последовательный (все штуки в модуле являются частью пайплайна И! принимают на вход то что вернул предыдущий этап этого пайплайна) - функциональная (благодать и SRP)

Серег, все плохо

Тебе бы проверится сходить

Тебе бы проверится сходить

пойду покурю...

виды кохижена (которые определяются вопросом "почему эти штуки вместе2) - случайный (рандом, утилиты) - логический (когда "логично" что оно вместе но это совсем разные штуки) - временной (штуки внутри модуля связывает только тот факт что мы вызываем их примерно в одно и то же время) - процедурный (штуки внутри модуля нужны для одного и того же алгоритма, хотя вне контекста алгоритма связи между ними нет) - информационный (все штуки в модуле работают с одними и теми же данными) - последовательный (все штуки в модуле являются частью пайплайна И! принимают на вход то что вернул предыдущий этап этого пайплайна) - функциональная (благодать и SRP)

? это ты сам их выделил ? или можно где-то подкрепить информацией это ?

? это ты сам их выделил ? или можно где-то подкрепить информацией это ?

можешь оригинальную книжку почитать или википедию)

можешь оригинальную книжку почитать или википедию)

а тебе кидали первоисточник по кохижену, да:

это я сейчас просто привел все виды которые есть в вики с описанием что бы понятно было

оно то да, но нет

оно то да, но нет

?

класификацию можно сделать, но зачем?

класификацию можно сделать, но зачем?

я пока не готов ответить на этот вопрос с 100% точностью, но пока предполагаю что основная ценность в том, что бы ответить на один простой вопрос - а как померять кохижен моего кода? Почему сеттеры снижают кохижен? Почему утил классы это дно? Куда мне вообще код ложить то?