TP
Это не физика, тут свои законы под каждый проект)
Size: a a a
2020 June 11
PP
Потому что термин один, а значения даже в одном контексте у разных собеседников зачастую разные.
A
Он асинхронный. Методы синхронные
Не уверен что Kay имел ввиду именно асинхронный messaging, ему не нравилось RPC потому что не было привязки к объектам, поэтому термин он и выбрал другой
MB
Ну по сути с "чистым" объектом мы получаем просто несколько замыканий, шарящих один энвайронмент. Не очень понятно, что с этим сделать, но подумать можно)
Н
Andrei
Не уверен что Kay имел ввиду именно асинхронный messaging, ему не нравилось RPC потому что не было привязки к объектам, поэтому термин он и выбрал другой
Я как-то ковырял все его письма и сам язык. И в ранних версиях была асинхронщина, но ее выпилили в итоге. Причину не помню
Н
Я тут уже задавал вопрос, но поскольку аудитория в дискуссии немного другая: вы какую архитектуру используете в своих проектах? И есть ли пример
MB
Я как-то ковырял все его письма и сам язык. И в ранних версиях была асинхронщина, но ее выпилили в итоге. Причину не помню
Мне на первый взгляд кажется, что не так важна асинхронщина, как невозможность изменить состояние объекта снаружи (то, что большинство популярных языков позволяют и делают простым)
MB
Local reasoning по-моему очень важен в любом языке
AC
А почему беда?
Беда в том что нет консенсуса, нет единого понимания, нет никакой теории
((
Я тут уже задавал вопрос, но поскольку аудитория в дискуссии немного другая: вы какую архитектуру используете в своих проектах? И есть ли пример
не знаю как тут, а ровно на одном месте где я работал архитектура была такая. В контроллере с помощью merge подправляем запрос в бд, а сервисе его вызываем! збс архитектура.
AC
Беда в том что нет консенсуса, нет единого понимания, нет никакой теории
А значит невозможно координированно развивать идеи ООП
Н
не знаю как тут, а ровно на одном месте где я работал архитектура была такая. В контроллере с помощью merge подправляем запрос в бд, а сервисе его вызываем! збс архитектура.
Хаха
MB
А значит невозможно координированно развивать идеи ООП
Вообще, слышал, но не проверял, что в эпоху развития ООП какая-то теория развивалась, типа Liskov substitution principle и пр.
((
это была моя "стрела в колене" от мира Clojure
((
и сколько я "realworld examples" не смотрел везде было примерно так же. Жирный сервис вместе с сайд эффектами и доменной логикой. Просто - безусловно! Хочется так писать - нет!
Н
и сколько я "realworld examples" не смотрел везде было примерно так же. Жирный сервис вместе с сайд эффектами и доменной логикой. Просто - безусловно! Хочется так писать - нет!
А вы как делаете сейчас?
((
чистый домен + репозитории и сервис, который умеет их связывать, но логики не содержит
Н
чистый домен + репозитории и сервис, который умеет их связывать, но логики не содержит
То есть юзкейс с бизнес логикой, который вызывает контроллер, типа того?
MB
чистый домен + репозитории и сервис, который умеет их связывать, но логики не содержит
А что такое сервис тогда?
((
То есть юзкейс с бизнес логикой, который вызывает контроллер, типа того?
не, controller -> service -> domain
-> db
-> db