ŹR
Впрочем, set_env если правильно сделать, а не через
@user_loader Application.ge… будет иметь возможность менять в рантаймеSize: a a a
2021 March 31
((
=)
T
менять можно, но другой вопрос что менять реализацию в рантайме это странное решение
++ в рантайме рекомендую менять только данные
T
По возможности
((
как типичный .Net разработчик мне такое и в голову не приходило
A
Раз, тут пошло оживление спрошу еще раз. Кто помнит статью про технику разделения логики и процессов в духе эффектов и их обработчиков? Тут проплаывала пару месяцев назад и я потерял ссылку :(
Aß
про окамл?
A
не не, конкретно про эликсир
((
о, тоже интересно
ML
Ну и в целом dependency injection нужен для решения проблемы создаваемой самим ООП.
Нет ООП - нет проблемы, не нужен injection
Нет ООП - нет проблемы, не нужен injection
почему? DI — это же способ передать ссылку на стороннюю функциональность.
Например не хардкодить обращение к конкретному HTTP клиенту, не пытаться иметь Один Единый Http Клиент во всей экосистеме, а передавать ссылку.
Например, MFA
Например не хардкодить обращение к конкретному HTTP клиенту, не пытаться иметь Один Единый Http Клиент во всей экосистеме, а передавать ссылку.
Например, MFA
V
DI как вариант полиморфизма
V
ООП (мэйнстримовый) - про полиморфизм через наследование. В точку вызова подсовывается другой объект-исполнитель с методом с такой же сигнатурой.
В эликсире тоже можно подменять модуль-исполнитель, как показано здесь https://t.me/proelixir/182362, только читаемость кода падает.
В эликсире тоже можно подменять модуль-исполнитель, как показано здесь https://t.me/proelixir/182362, только читаемость кода падает.
V
Откуда вообще в ООП зависимости, что их необходимо инвертировать? Оттуда, что обычный ООП-стиль конструирования программ - это наинстанцировать объектов и засовывать их друг в друга. Отсюда высокая сложность чтения ООП-кода собранного на основе интерфейсов - нужно понимать, какая реализация засунута в эту зависимость, какая в эту. Бывают тяжёлые случаи, когда зависимости вычисляются на лету, и простым чтением понять невозможно, приходится код запускать и интроспектить. Рано или поздно ООПшник приходит к мысли, что лучше иметь по одной реализации на интерфейс. Но тогда чем это будет отличаться от чистых не привязанных к контексту функций с хардкодными зависимостями? Ничем. Эликсир-код проще читать чем ООП-лапшу.
T
V
Откуда вообще в ООП зависимости, что их необходимо инвертировать? Оттуда, что обычный ООП-стиль конструирования программ - это наинстанцировать объектов и засовывать их друг в друга. Отсюда высокая сложность чтения ООП-кода собранного на основе интерфейсов - нужно понимать, какая реализация засунута в эту зависимость, какая в эту. Бывают тяжёлые случаи, когда зависимости вычисляются на лету, и простым чтением понять невозможно, приходится код запускать и интроспектить. Рано или поздно ООПшник приходит к мысли, что лучше иметь по одной реализации на интерфейс. Но тогда чем это будет отличаться от чистых не привязанных к контексту функций с хардкодными зависимостями? Ничем. Эликсир-код проще читать чем ООП-лапшу.
А может прийти к композиции
V
А может прийти к композиции
кто/что?
T
V
кто/что?
"ООПшник приходит к мысли"
V
Это фигура речи. ООПшник никуда особо не ходит
а
V
Это фигура речи. ООПшник никуда особо не ходит
Но к композиции прийти может
V
Как только ООПшник приходит к композиции - он начинает испускать из глаз особые лучи, другие ООПшники их видят, и начинают его кусать
AD
V
Откуда вообще в ООП зависимости, что их необходимо инвертировать? Оттуда, что обычный ООП-стиль конструирования программ - это наинстанцировать объектов и засовывать их друг в друга. Отсюда высокая сложность чтения ООП-кода собранного на основе интерфейсов - нужно понимать, какая реализация засунута в эту зависимость, какая в эту. Бывают тяжёлые случаи, когда зависимости вычисляются на лету, и простым чтением понять невозможно, приходится код запускать и интроспектить. Рано или поздно ООПшник приходит к мысли, что лучше иметь по одной реализации на интерфейс. Но тогда чем это будет отличаться от чистых не привязанных к контексту функций с хардкодными зависимостями? Ничем. Эликсир-код проще читать чем ООП-лапшу.
Мощно, красиво