Но можно.

Через reflection механизм.

Конкретной платформы.

Но это гемор.

я даже слов таких не знаю

Хорошо, когда ты поправил баг из баг трекера твоего проекта, то что ты делаешь, чтобы баг в будущем опять не вылез?

да понятия не имею

я таких проектов не делаю. наверное что-то с этим делают

Без IoC довольно сложно что-то мочить.

еще один ООПшник?

я таких проектов не делаю. наверное что-то с этим делают

В твоём коде нет багов?

еще один ООПшник?

обрати внимание - явист. вот они свою жабу за собой как писаную торбу таскают

В твоём коде нет багов?

конечно есть

обрати внимание - явист. вот они свою жабу за собой как писаную торбу таскают

вот-вот. будто иначе нельзя нигде и никак писать.

конечно есть

А как тогда пользователи (необязательно end user'ы в привычном их понимании, а скажем end developers твоего middleware кода) тебе сообщают о багах?

вот-вот. будто иначе нельзя нигде и никак писать.

Эм, так я выше и попросил реальные примеры.

Как производится decoupling на pure FP?

Я ведь не декларировал, что ООП подход единственно верный.

с pure fp ты явно каналом ошибся.. )

где го и где pure fp....

с pure fp ты явно каналом ошибся.. )

Хорошо, люди сказали, что подходы ООП не работают. Мне и стало интересно при помощи каких подходов они тестируют код и отвязывают его внутренние части друг от друга. ?

Интересна ведь дискуссия.

И кто как делает.

велосипедят все тот же IoC но руками и потом себе в этом не признаются

О чем эти люди вообще?

О чем эти люди вообще?

я что-то тоже не понял.

с чистым пюр все зависимости будут прокидывать в функцию :) но вообще не делал этого с fp

ну pure это не про го )

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

ну pure это не про го )

ещё

с чистым пюр все зависимости будут прокидывать в функцию :) но вообще не делал этого с fp

High order anonymous functions во все поля?

High order anonymous functions во все поля?

ШТОА

Или как это правильно назвать.

Ну, я не силён в терминологии ФП.

Пайк давно экспериментирует с функциональщиной. может, что-то вкрутит.

{:ok, conn} = AMQP.Connection.open {:ok, ch} = AMQP.Channel.open(conn) AMQP.Queue.declare(ch, "hello") sending(ch) AMQP.Connection.close(conn)

Пайк давно экспериментирует с функциональщиной. может, что-то вкрутит.

мы столько не проживем

ch и есть нужная структура с конектом и прочим

если то что в го называется “экспериментирует с функциональщиной” то до текущего state of art он будет это лет 50 тащить

так что нет проблем

мы столько не проживем

конечно. мы в гудланг раньше вкрутим.

ООП о другом

:)

{:ok, conn} = AMQP.Connection.open {:ok, ch} = AMQP.Channel.open(conn) AMQP.Queue.declare(ch, "hello") sending(ch) AMQP.Connection.close(conn)

Угу, верно, а теперь надо автоматизировать создание AMQP.Connection.open и автоматическую передачу его во AMQP.Channel.open. ?

Ну и так далее.

руками тащи

руками тащи

А если хочу одну реализацию подсовывать в 100 500 местах по коду? ?

Grep'ать?

Или factory function мутить? ?

factory и опять же руками )

обрати внимание - явист. вот они свою жабу за собой как писаную торбу таскают

ну опять, смотри

для этого есть протоколы, бихеверы и прочее

можешь мокать как угодно

для этого есть протоколы, бихеверы и прочее

Что такое behavior? Как в Ruby?

как интерфес в го

А, ок.

я что-то тоже не понял.

Ну я на самом деле примерно понимаю. Жаба и плюсы они ынтырпрайз. Т.е. это четкие стратегии и методики. Не всегда оптимальные. Но всегда чОткие. В этом даже что-то есть. Хочешь ты не хочешь, а твой год будет разрабатываться и тестироваться по идентичным методикам. И это даже хорошо. Ну и обвязка ООП порождает такое монструозное окружение. С крутыми ынтырпрайзными словами. В которые начинают верить и гордиться. Ну вот мы и видим

Ну я на самом деле примерно понимаю. Жаба и плюсы они ынтырпрайз. Т.е. это четкие стратегии и методики. Не всегда оптимальные. Но всегда чОткие. В этом даже что-то есть. Хочешь ты не хочешь, а твой год будет разрабатываться и тестироваться по идентичным методикам. И это даже хорошо. Ну и обвязка ООП порождает такое монструозное окружение. С крутыми ынтырпрайзными словами. В которые начинают верить и гордиться. Ну вот мы и видим

тут о ddd

Ну я на самом деле примерно понимаю. Жаба и плюсы они ынтырпрайз. Т.е. это четкие стратегии и методики. Не всегда оптимальные. Но всегда чОткие. В этом даже что-то есть. Хочешь ты не хочешь, а твой год будет разрабатываться и тестироваться по идентичным методикам. И это даже хорошо. Ну и обвязка ООП порождает такое монструозное окружение. С крутыми ынтырпрайзными словами. В которые начинают верить и гордиться. Ну вот мы и видим

обвязка ооп? ) сдай дилера, хорошую он тебе дурь завозит

тут о ddd

dурак-driven-development или что?

Ну я на самом деле примерно понимаю. Жаба и плюсы они ынтырпрайз. Т.е. это четкие стратегии и методики. Не всегда оптимальные. Но всегда чОткие. В этом даже что-то есть. Хочешь ты не хочешь, а твой год будет разрабатываться и тестироваться по идентичным методикам. И это даже хорошо. Ну и обвязка ООП порождает такое монструозное окружение. С крутыми ынтырпрайзными словами. В которые начинают верить и гордиться. Ну вот мы и видим

Да никто ничем не гордиться. Могу и скрипт налабать на лапше и функциональной композиции простой, если этого достаточно будет.

?

Да никто ничем не гордиться. Могу и скрипт налабать на лапше и функциональной композиции простой, если этого достаточно будет.

этого всегда достаточно

Ну я на самом деле примерно понимаю. Жаба и плюсы они ынтырпрайз. Т.е. это четкие стратегии и методики. Не всегда оптимальные. Но всегда чОткие. В этом даже что-то есть. Хочешь ты не хочешь, а твой год будет разрабатываться и тестироваться по идентичным методикам. И это даже хорошо. Ну и обвязка ООП порождает такое монструозное окружение. С крутыми ынтырпрайзными словами. В которые начинают верить и гордиться. Ну вот мы и видим

это-то понятно. но в этом мире нужно быть гибче.

dурак-driven-development или что?

не, я немного другое изучал

этого всегда достаточно

точнее так. нет ничего, что требовало бы ООП. и нет полярного мира ООП vs "налабаная лапша"

Хорошо, люди сказали, что подходы ООП не работают. Мне и стало интересно при помощи каких подходов они тестируют код и отвязывают его внутренние части друг от друга. ?

Интерфейсы жи. И вообще, в фейсбучиках пишут, что юнит-тесты не нужны. Функциональные всё покрывают, что надо.

Интерфейсы жи. И вообще, в фейсбучиках пишут, что юнит-тесты не нужны. Функциональные всё покрывают, что надо.

Я не вижу связи юнит/функциональных тестов с ООП.

ERROR: S client not available

Я не вижу связи юнит/функциональных тестов с ООП.

Товарищ спрашивал, как код друг от друга отделять. Хотя, может, я плохо понял, что он имел в виду. И в любом случае я не понял, как это в ООП.

Товарищ спрашивал, как код друг от друга отделять. Хотя, может, я плохо понял, что он имел в виду. И в любом случае я не понял, как это в ООП.

Я вообще не понял, что он имел ввиду. Зачем код отделять?

он хотел готовое решение для IoC в го

Я вообще не понял, что он имел ввиду. Зачем код отделять?

Чтоб тестировать ж. Если я правильно понял.

он хотел готовое решение для IoC в го

Оно и есть: https://github.com/go-ozzo/ozzo-di

Чтоб тестировать ж. Если я правильно понял.

эээээ.... поясни на пальцах

Оно и есть: https://github.com/go-ozzo/ozzo-di

рефлект на рефлекте, ну хз

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

нет ничего лучше myInterceptor.dependency1 = dependency1 myInterceptor.dependency2 = dependency2 myInterceptor.dependency3 = dependency3 myInterceptor.DoMyWork()

если сделать так: select { case act <-q } то без default это будет такое же блокирующее чтение из канала?

да

теперь понятно что за 3 дня отжирало 17 Gb ram

нет ничего лучше myInterceptor.dependency1 = dependency1 myInterceptor.dependency2 = dependency2 myInterceptor.dependency3 = dependency3 myInterceptor.DoMyWork()

тут и можно мокать зависимости, подсовывать бд, сервисы, io

эээээ.... поясни на пальцах

Ну типа, в ООП это что-то типа того. Есть у меня класс, который должен забирать из БД данные, обрабатывать и класть в файлик, например. И у него внутри метод, doAll() { bd = BD() f = File() data = bd.getData() f.put(data) } И вот этот метод не протестировать юнит-тестами без базы и файла реального. А можно сделать так: doAll(bdInterface, f fileInterface) { data = bdInterface.getData() f.put(data) } И ему уже можно всё, что угодно скормить вместо базы и файла, заглушки какие-нибудь.

Или можно в конструкторе класса давать ему интерфейс бд и файла. И потом через this их дёргать.

В джавах вроде для этого можно всяких xml-штуки писать, чтоб оно само делалось, или всякие фабрики строить.

Спасибо

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

Есть, кстати, годная книжка Michael Feathers - Working Effectively with Legacy Code, про вот всякую эту связность кода, тесты и прочее.

зашло конечно

должно было быть php :)

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

да и не обязательно fp

к слову о js, самое кошерное функциональное там purescript

я не увидел плюсов овер elm, правда давно сравнивал

ну тайпклассы? composable effects?

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

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

http://hacklang.org/

Для HHVM правда.

Но это ООП конечно.

elm решает конкретную задачу - ui, он и проще, и тулчаин помощнее, вывод ошибок изумительный что там пюрскрипт решает я пока не знаю, может позже уделю ему время, есть еще всякие ghcjs