С чего она потокобезопасная вдруг стала? Там просто всё в основном потоке, это ж VCL )). Потокобезопасность обеспечивает Винда. Цикл обработки сообщений крутится в главном потоке. Нет там нигде никакой синхронизации в коде Delphi. И я не про windowsMessage вообще, не про оконные сообщения и их обработку. Я про коллбеки обычные говорил. Типа - объект имеет поле “FOnCreate: TNotifyEvent” и другой объект в это поле кладет свой коллбэк: Obj.OnCreate := … И вот тут возникает связанность, от которой спасает паттерн Pub/Sub как раз.
Ну вообще, я использовал раньше в проектах на Delphi подобный Notifiyer для сложных проектов, где один компонент должен уведомлять о чем-то в процессе работы другой компонент. Раньше для этого в Delphi использовали TNotifyEvent и подписывались, передавая хэндлер (коллбэк) - OnEvent. И всё это делало код очень связанным и запутанным. Так написан весь VCL в Delphi. Начиная с Delphi XE5 в нем появилась либа System.Messaging подобная тому, что я описал в статье. Использовать её после TNotifyEvent - просто кайф )). Собственно, глядя на неё и статью писал. И эти библиотеки не подразумевают хранение и передачу истории сообщений, динамическое подключение подписчиков. Это уже, на мой взгляд - другое. Это уже - брокер сообщений полноценный. Это гораздо больше. Как-то так )
Предполагается, что все подписки инициализируются при старте приложения. Как любые другие зависимости. Вы же не говорите, что, допустим, накладываются ограничения на HTTP сервер из-за того, что БД не инициализирована до его старта? Это не полноценный брокер сообщений для микросервисов и хранить сообщения он не должен, ИМХО. Впрочем, если нужен именно такой сценарий - нужно сочинять что-то другое, не спорю.
Ну если нештатно, тогда всё что угодно можно предполагать ). Тут и редиски с кроликами не помогут ))). Безусловно, в описанной тобой ситуации нужно не просто пулять сообщения, а что-то придумывать. Я когда писал либу и статью, ориентировался на System.Messaging в Delphi https://docwiki.embarcadero.com/CodeExamples/Athens/en/System.Messaging_(Delphi). По опыту знаю - очень удобная штука для сложных проектов. Кардинально уменьшает связанность и хаос в коде.
Это не проблема, ИМХО. Это же внутрисервисные сообщения - между компонентами одного приложения. Завершилась работа сервиса, завершились и внутренние сообщения и компоненты уничтожились. Это не замена Кролику )
Подписчик не может не вычитывать - это часть Notifiyer. Но вот если хэндлер подписчика будет долго тупить - заблокируется. В конце статьи есть об этом. В боевом коде конечно так лучше не делать. И в библиотеке я предусмотрел несколько стратегий на этот счет
"Не закрытый канал держит ресурсы. Закрывать надо явно." - поправьте пожалуйста. Нужно писать "Незакрытый" - слитно. Иначе меняется смысл предложения. Типа - "Не закрытый канал держит ресурсы (а открытый)".
Я больше 20 лет работал в компании, которая фактически была моей второй семьей. Был вовлечен, перерабатывал, всячески старался работать именно на результат, а не на себя. Компания платила мне взаимностью и в деньгах и в карьере и в льготах и в человеческом отношении. Жалею, что ушел оттуда... Поверьте, такое бывает. Но видимо - редко.
С чего вдруг? Я про то что: Вы продаете своё время, свои способности, свою свободу. Если вы продаете честно качественный продукт и покупатель соблюдает условия договора - нет проблем. И усложнять ни к чему, ИМХО.
Неверно. Если работодатель нормальный - вы работаете сообща и получается синергия. Если каждый из вас думает только о своей выгоде - получается шляпа, как ни старайся. Но справедливости ради - адекватный работодатель встречается нечасто. Мне вот повезло, когда я попал в 1С-Рарус. Но больше с таким не сталкивался...
Так кроме прочего, я сам ежедневно пользуюсь ИИ при разработке и не только. И знаю, где и как он может быть полезен, где - опасен в программировании )). Однозначно, никакой нормальный софт с помощью вайб-кодинга создать нельзя. Это будет шляпа )).
Про Кибердеда: Я таки ему больше склонен доверять, чем вам. "Советкскость" тут не при чем. Он аргументирует, а вы просто вешаете ярлык "советская газета".
P.S. Просьба - ставить хоть какие-то знаки препинания. Последний ваш абзац нечитабелен ((. "КосТность мышления" - пять баллов )). Извините, не удержался.
Абсолютно нормальное мироустройство. Ты честно работаешь, тебе честно платят. Когда вам за большую сумму продают бракованный негодный товар, вы тоже размышляете про общественное устройство? Отношения между работодателем и работником - это обычный договор купли-продажи. Ты - мне, я - тебе ).
С чего она потокобезопасная вдруг стала? Там просто всё в основном потоке, это ж VCL )). Потокобезопасность обеспечивает Винда. Цикл обработки сообщений крутится в главном потоке. Нет там нигде никакой синхронизации в коде Delphi. И я не про windowsMessage вообще, не про оконные сообщения и их обработку. Я про коллбеки обычные говорил. Типа - объект имеет поле “FOnCreate: TNotifyEvent” и другой объект в это поле кладет свой коллбэк: Obj.OnCreate := … И вот тут возникает связанность, от которой спасает паттерн Pub/Sub как раз.
Я сделал простейшие обертки для System.Messaging для работы в потоках. И если слать record-ы а не объекты - вообще проблем нет.
Ну вообще, я использовал раньше в проектах на Delphi подобный Notifiyer для сложных проектов, где один компонент должен уведомлять о чем-то в процессе работы другой компонент. Раньше для этого в Delphi использовали TNotifyEvent и подписывались, передавая хэндлер (коллбэк) - OnEvent. И всё это делало код очень связанным и запутанным. Так написан весь VCL в Delphi. Начиная с Delphi XE5 в нем появилась либа System.Messaging подобная тому, что я описал в статье. Использовать её после TNotifyEvent - просто кайф )). Собственно, глядя на неё и статью писал. И эти библиотеки не подразумевают хранение и передачу истории сообщений, динамическое подключение подписчиков. Это уже, на мой взгляд - другое. Это уже - брокер сообщений полноценный. Это гораздо больше. Как-то так )
Вы правы. Всё есть тут: https://github.com/istovpets/messaging/blob/master/messaging.go#L237 А в данной статье - нарочито упрощенный учебный пример.
Предполагается, что все подписки инициализируются при старте приложения. Как любые другие зависимости. Вы же не говорите, что, допустим, накладываются ограничения на HTTP сервер из-за того, что БД не инициализирована до его старта? Это не полноценный брокер сообщений для микросервисов и хранить сообщения он не должен, ИМХО. Впрочем, если нужен именно такой сценарий - нужно сочинять что-то другое, не спорю.
Ну если нештатно, тогда всё что угодно можно предполагать ). Тут и редиски с кроликами не помогут ))). Безусловно, в описанной тобой ситуации нужно не просто пулять сообщения, а что-то придумывать. Я когда писал либу и статью, ориентировался на System.Messaging в Delphi https://docwiki.embarcadero.com/CodeExamples/Athens/en/System.Messaging_(Delphi). По опыту знаю - очень удобная штука для сложных проектов. Кардинально уменьшает связанность и хаос в коде.
Это не проблема, ИМХО. Это же внутрисервисные сообщения - между компонентами одного приложения. Завершилась работа сервиса, завершились и внутренние сообщения и компоненты уничтожились. Это не замена Кролику )
Подписчик не может не вычитывать - это часть Notifiyer. Но вот если хэндлер подписчика будет долго тупить - заблокируется. В конце статьи есть об этом. В боевом коде конечно так лучше не делать. И в библиотеке я предусмотрел несколько стратегий на этот счет
"Не закрытый канал держит ресурсы. Закрывать надо явно." - поправьте пожалуйста. Нужно писать "Незакрытый" - слитно. Иначе меняется смысл предложения. Типа - "Не закрытый канал держит ресурсы (а открытый)".
Спасибо на добром слове )
Не готов спорить, о преимуществах коммунизма перед капитализмом и рынка перед планом )). Да и не то это место для подобных споров )).
Вы говорите совсем о другом ). Да, не один идиот себя идиотом не считает )).
Я больше 20 лет работал в компании, которая фактически была моей второй семьей. Был вовлечен, перерабатывал, всячески старался работать именно на результат, а не на себя. Компания платила мне взаимностью и в деньгах и в карьере и в льготах и в человеческом отношении. Жалею, что ушел оттуда...
Поверьте, такое бывает. Но видимо - редко.
С чего вдруг? Я про то что: Вы продаете своё время, свои способности, свою свободу. Если вы продаете честно качественный продукт и покупатель соблюдает условия договора - нет проблем.
И усложнять ни к чему, ИМХО.
Неверно. Если работодатель нормальный - вы работаете сообща и получается синергия. Если каждый из вас думает только о своей выгоде - получается шляпа, как ни старайся. Но справедливости ради - адекватный работодатель встречается нечасто. Мне вот повезло, когда я попал в 1С-Рарус. Но больше с таким не сталкивался...
Так кроме прочего, я сам ежедневно пользуюсь ИИ при разработке и не только. И знаю, где и как он может быть полезен, где - опасен в программировании )). Однозначно, никакой нормальный софт с помощью вайб-кодинга создать нельзя. Это будет шляпа )).
Про Кибердеда: Я таки ему больше склонен доверять, чем вам. "Советкскость" тут не при чем. Он аргументирует, а вы просто вешаете ярлык "советская газета".
Моё личное мнение: Языковая модель, использующая вероятностную статистику по определению не может писать полноценный код. И если самому ChatGPT правильно сформулировать вопрос - "Почему?", он сам вам о себе расскажет.
Вот пример:
https://www.linkedin.com/posts/istovpets_если-правильно-задать-вопрос-ии-он-сам-объяснит-activity-7432194691946840064-4_sW?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAAEJkQY4BXOtXuHOzOy6UuD5_5wWo_AWx5bI
P.S. Просьба - ставить хоть какие-то знаки препинания. Последний ваш абзац нечитабелен ((.
"КосТность мышления" - пять баллов )). Извините, не удержался.
Ну или вот: https://www.rbc.ru/business/20/02/2026/6997e0949a7947733677f835
Выводы исходят и разрозненных источников. Новости, интервью, статьи. К сожалению, не сохранял ссылки. Ну например, вот: https://youtu.be/8Bm6LOFn6l8?si=RbotH9L3PgKELoIy
Абсолютно нормальное мироустройство. Ты честно работаешь, тебе честно платят. Когда вам за большую сумму продают бракованный негодный товар, вы тоже размышляете про общественное устройство?
Отношения между работодателем и работником - это обычный договор купли-продажи. Ты - мне, я - тебе ).
Да нет, почему же сразу болен? Это чувство стаи, чувство команды )). Если работодатель при этом адекватный - то только так и покоряются вершины ).