Я такой - э, а как сделать синглтон? А мне говорят - не делай синглтон, делай модуль

не обязательно делать модуль http://ideone.com/cg8YxQ

Развиваешься только когда встречаешься с чем-то новым

В си-подобных имхо всё это гораздо удобнее, хотя питон и считается простым языком

Что удобнее? Ты объяснить можешь в чём у тебя претензия?

Я такой - э, а как сделать синглтон? А мне говорят - не делай синглтон, делай модуль

Зачем делать синглтоны :/

а кто то не переваривает си. а только жс

А какие в сишке интерфейсы? О.о

я с руби тоже толго мучался

Ладно, очередной разговор ни о чём

Что удобнее? Ты объяснить можешь в чём у тебя претензия?

Так, глобально, нет. Но чуть ли не каждую штуку сложнее print() которую я привык делать на яве/пхп приходится делать совершенно по другому, как будто изучаю программирование с нуля.

Это не претензия, просто несколько неприятно ощущать себя снова тупым новичком

Так, глобально, нет. Но чуть ли не каждую штуку сложнее print() которую я привык делать на яве/пхп приходится делать совершенно по другому, как будто изучаю программирование с нуля.

Почему по другому? Ты не указываешь тип => тебе не нужны интерфейсы

В остальном код пишется так же

Зачем делать синглтоны :/

Вот хороший вопрос я тоже иногда об этом думаю. На вскидку мне приходит идея с логированием и общими настройками для всего приложения.

Вот хороший вопрос я тоже иногда об этом думаю. На вскидку мне приходит идея с логированием и общими настройками для всего приложения.

А что с логгированием? Запрашивай логгер как модуль

В самом приложении регистрируется уже конкретный логгер

Вот хороший вопрос я тоже иногда об этом думаю. На вскидку мне приходит идея с логированием и общими настройками для всего приложения.

Зачем это делать синглтонами?

если нужен синглтон значит что-то делаешь не так

Синглтон нужен, кто бы чего не говорил. Для того же хранения неких настроек в небольших приложениях.

Вы конечно палками сейчас будете кидать и бить, но всё же)

Я пропустил, чем плох синглтон?

Ну как сказать плох. Просто его применять необходимо в нужном месте в нужное время.

Я пропустил, чем плох синглтон?

Тем, что это модуль?

Синглтон нужен, кто бы чего не говорил. Для того же хранения неких настроек в небольших приложениях.

Зачем?

Не понял, какая связь между модулем и синглтоном?

Если тебе нужен синглтон, то на самом деле тебе нужен модуль

Модуль же про инкапсуляцию, а синглтон про то, что всего один экземпляр. И уж какой интерфейс этот синглтон выставляет - наплевать. Скрыть в модуле единое хранилище - да, оно будет похоже на синглтон, но все равно про другое паттерн...

Посыл понял

Эм. Чтоа

Ты с синглтоном общаешься через его интерфейс, как и с модулем

Ты рассчитываешь на то, что это единый объект. Как и с модулем

Хер ты от него унаследуешься, лол. Как и с модулем

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

Модуль не паттерн, а механизм языка

И там где его нет и нужны синглтоны (java, если что)

А, вот о чем речь.

Ну в общем да, синглтон эт костылек такой

Зачем это делать синглтонами?

А почему нет? Эти вещи точно нужны в 1 единственном экземпляре причем они могут иметь свой внутренний стейт который может меняться в процессе работы приложения.

А почему нет? Эти вещи точно нужны в 1 единственном экземпляре причем они могут иметь свой внутренний стейт который может меняться в процессе работы приложения.

Пускай о том, в скольки экземплярах онинужны заботится кто-то еще

И еще лучше, пускай от них мало кто зависит

Чем сложнее к ним достучаться тем лучше

Чем сложнее к ним достучаться тем лучше

чем сложнее достучаться до системы логирования тем лучше?

Да

И до конфигов

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

Пускай о том, в скольки экземплярах онинужны заботится кто-то еще

И кто же это будет?

А почему нет? Эти вещи точно нужны в 1 единственном экземпляре причем они могут иметь свой внутренний стейт который может меняться в процессе работы приложения.

Современная форма синголтона - локатор

Сервислокатор - форма DI

Вот его и надо юзать, вместо древнего стандартного синглтона

Сервис локатор это форма IoC

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

Не думаю, что это хороший способ трека информации про клиента

одно и тоже

Думаю, что плохой

Само собой не захордкоженый локатор, а нормальный гибкий локатор - для высокопроизводительных приложений не подходит

Если передовать локатор в виде параметра конструктора оно смотрится както не очень

не обязательно передавать

Передавайте сразу нужнве зависимости, зачем локатор-то?

просто юзай как древний синглтон его

Тогда он от сингелтона не будет отличаться ))

будет за счет DI функционала

https://ideone.com/obc4fz

Передавайте сразу нужнве зависимости, зачем локатор-то?

зачем передавать зависимость от логерра если от него зависит любой класс в системе?

Если у вас от чего-то зависит любой класс в системе, то вы проиграли)

Передавайте сразу нужнве зависимости, зачем локатор-то?

В таком случае я буду вынужден пробрасывать указатели на класс логирования по всему стеку вызовов. Что усложнит как написание так и понимание кода.

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

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

не могли бы вы кодом прокомментировать свою позицию. К сожелению пока у меня сложилось впечатление что предлагаеться подобный подход https://ideone.com/t9DISm . Думаю тут я заблуждаюсь и просто неверно вас понял.

ERROR: S client not available

в контексте питона решение супер простое - модули, а вообще https://gist.github.com/mkusher/97f6ff29f73b536c5b7f31c6a3f407c2 ни B, ни C не знают ни про какой log и знать про него не должны

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

Логгер доступен каждому, это нормально, включая third party модули. И уже в конечном приложении определяется кто и как логируется конкреным логгером (каким-нибудь env-специфичным для разработки и стримовым в файл для прода). Пробрасывать его не надо, ибо к логике работы модуля он отношения не имеет

Логгер доступен каждому, это нормально, включая third party модули. И уже в конечном приложении определяется кто и как логируется конкреным логгером (каким-нибудь env-специфичным для разработки и стримовым в файл для прода). Пробрасывать его не надо, ибо к логике работы модуля он отношения не имеет

нет, не каждому. Есть куча логики того же домена, которая ничего сама не логирует

есть декораторы, которые гоняют домен и могут логировать вокруг вызова, есть эффекты и евенты, на основе которых может быть лог

нет, не каждому. Есть куча логики того же домена, которая ничего сама не логирует

Логирование это не какая-то особая прерогатива

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

есть модули - не надо, нет модулей - надо)

Логирование это не какая-то особая прерогатива

такая же особая, как рендерить хтмл

Рендерить хтмл это часть бизнес-процесса

И код описывает бизнес-логику

которая не находится среди домена

а находится где-то в ui

Логирование это средство инспектирования и к задаче отношения не имеет

а находится где-то в ui

Это конечная цель.

может да, может нет

То, что в логи в итоге будет попадать только нужные нам модули это понятно

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

а главное зачем?

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

Как бы есть подход и для чистых языков: когда возвращается всегда тип аля Result<T>, который на самом деле пара результат и строка (сообщене) и протаскивается через систему.

Вот только одна тонкость

Это нахуй не нужно никому

И знаешь почему?

ну конкретно с логами был бы Log a или Writer a String

Поэтому хаскель и не станет мейнстримом

потому что нельзя логи пропихнуть туда, где им не место?)

Потому что код должен выполнять конкретную бизнес задачу, либо быть утилитарным для кода, который будет выполнять бизнес задачу. И код это должен быстро писаться и быстро читаться. А для этого он должен быстро дебажиться. А для этого он должен быть обложен логированием, ассертами и так далее

потому что нельзя логи пропихнуть туда, где им не место?)

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

а еще всякие штуки типа AOP профайлинга

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

а еще всякие штуки типа AOP профайлинга

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