никто не хочет похоливарить на тему иммутабельность vs инкапсуляция?

Эм? А почему это противопоставляется?

почему vs?

?

ну и где обещанный холивар?(

не вышло у Олег затеять его.

а, отвлекся

спакуха

ну, вопрос можно поставить иначе: зачем вам инкапсуляция, когда есть иммутабельность?

Сергей(

ну, вопрос можно поставить иначе: зачем вам инкапсуляция, когда есть иммутабельность?

эм....

вот щас он ответит на вопрос и будет неинтересно

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

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

а не, не ответил, продолжаем)

ну то есть если ты под инкапсуляцией понимаешь только data hiding

то да, тогда не нужна

но инкапсуляция это не только data hiding

я ничего не подразумеваю, вопрос взят из очередного высера на тему фп vs ооп

ааа

но инкапсуляция это не только data hiding

data hiding это больше сайд-эффект

ну тип того

ну, вопрос можно поставить иначе: зачем вам инкапсуляция, когда есть иммутабельность?

В фп тоже практикуют скрытие реализации также как и в ооп. И в принципе любое скрытие реализации необходимо для построения абстракций.

я ничего не подразумеваю, вопрос взят из очередного высера на тему фп vs ооп

а в ооп нельзя жить с иммутабельностью?

в ооп хорошо с иммутабельностью, естественно не везде она нужна

а в ооп нельзя жить с иммутабельностью?

можно

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

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

может к лямбда исчислениям тогда уже?

там тебе и имутабельность (потому что нет стэйта), и абстракция, и декомпозиция...

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

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

может к лямбда исчислениям тогда уже?

к алгебре начальных классов тоже можно притянуть)

а в ооп нельзя жить с иммутабельностью?

даже больше. По возможности стоит делать все неизменяемым это упрощает не только нахождение ошибок но и предотвращает некоторые весьма специфические.

но надо помнить, что иммутабельность порождает другой класс ошибок

неконсистентность?

ага

где чего почитать на тему eventual consistency

норм вопрос

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

Потому что это относится к фп внезапно.

где чего почитать на тему eventual consistency

а ты в каком-то контексте хочешь?

Потому что это относится к фп внезапно.

точно так же как и к ООП

а ты в каком-то контексте хочешь?

да не особо

Эм. А в чем холивар-то?

определения, как бы, разные.

Потому что это относится к фп внезапно.

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

определения, как бы, разные.

?

определения чего?

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

хм, а механиз искобчений — это сайд эффекты?

хм, а механиз искобчений — это сайд эффекты?

да, но посмотри на go - там нет исключений)

там туплы

или посмотри на erlang

ты правда считаешь тапл и эррор код

это лучше хорошая идея?

это лучше хорошая идея?

это нормальная идея. Точно такая же как исключения

явная обработка ошибок

и выбор обрабатывать ошибку или нет

ну то есть не могу сказать что это лучше но это явно

но, это добавляет механину матчинга в язык

но, это добавляет механину матчинга в язык

?

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

в отличии от исключений где все происходит неявно

это не лучше и не хуже

просто по другому

?

что бы заматчить результат в переменные.

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

Я не очень шарю в го, что он вернет вместо результата при ошибке?

(error, null)?

ERROR: S client not available

тип того

if (error != nill)

где там эта картинка

http://i0.kym-cdn.com/photos/images/original/001/167/690/e55.png

ну по сути если бы был еще один уровень return типа эксепшена, то получилось бы тоже самое, но это было бы тож не особо удобно из-за роста списка

ну этот throws из жавы

в целом разницы никакой нет

ну то есть да

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

вопрос в сахарке

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

а как их обрабатывать дело уже ваше типа

т.е. привет проверямые исключения

и есть только они

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

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

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

ну если бы для этого сахарок был)

ну если бы для этого сахарок был)

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

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

любой разговор о го, этим заканчивается

но хз, я на go писал только хелло ворлды на вэбсокетах, мало практики

А как в эрланге и исключениями?

Привет всем, тут есть джависты?))

Привет всем, тут есть джависты?))

Тут все ООПшники.

+

Есть такой грех.

ахах

Привет всем, тут есть джависты?))

нет

Это как в пропасть катиться. Остановиться уже не сможешь(

хотел спросить play или wicket?

А как в эрланге и исключениями?

норм. там исключения больше похожи на просто сообщения между процессами.

норм. там исключения больше похожи на просто сообщения между процессами.

а как ты их от результата отличаешь