ДБ
По идее мне нужно bindEnv (bindAsync (...?))
Size: a a a
2020 October 23
ДБ
В этом случае в save по идее должно быть
HasStore & HasLogger & HasConfig
??
HasStore & HasLogger & HasConfig
??
g
В этом случае в save по идее должно быть
HasStore & HasLogger & HasConfig
??
HasStore & HasLogger & HasConfig
??
Да, я сначала пропустил, что в
save есть логгирование. Но вызов Logger.log автоматически добавляет констрейнты HasLogger и HasConfig.g
А можно еще ревизию
Я не уверен, что это хорошая идея. Придется все функции в
Env заворачивать.ДБ
Понял
PD
AH
https://gist.github.com/Prunkles/16b6d681214ffc623d44a5d1410957ce
Можно и без сртпшек
Можно и без сртпшек
Интерфейсы на чужой тип не насунешь
PD
Интерфейсы на чужой тип не насунешь
Экстеншн методы на данный момент тоже!
AH
Экстеншн методы на данный момент тоже!
Тоже верно. Но уже почти!!1
PD
+ Нет проблем с возможными коллизиями имён
g
https://gist.github.com/Prunkles/16b6d681214ffc623d44a5d1410957ce
Можно и без сртпшек
Можно и без сртпшек
Захотелось использовать анонимные записи, чтобы делать композицию зависимостей.
PD
Захотелось использовать анонимные записи, чтобы делать композицию зависимостей.
Так она и так тоже делается. Итоговая функция (
logField) требует реализацию сразу двух интерфейсов — вот тебе и композицияPD
Так или иначе, самое приятное, что использующий код совершенно не зависит от выбранного подхода. Нужно просто изменить функции, которые задают эту зависимость (
Log.info, Config.getField) , и всё, ты уже используешь не интерфейсы, а снова сртпPD
Захотелось использовать анонимные записи, чтобы делать композицию зависимостей.
А, я понял о чём речь шла. Ну, технически object expression тоже смог бы такое с интерфейсами, пусть и менее удобно
g
А, я понял о чём речь шла. Ну, технически object expression тоже смог бы такое с интерфейсами, пусть и менее удобно
Да.
PD
Но у меня цель — абьюзить фичи. :)
Абьюз засчитан, но мне кажется не очень удачным решением инлайн функций с логикой (
Logger.log, Storage.save)