больше на ивенты похоже

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

вот здесь меня и ломает, что calll сообщением переводят

туда вызов от туда события?

В обоих направлениях перемещаются сообщения

Больше ничего нет, в этом суть

Посоветуете подкасты по пхп и программированию в целом плз

вот здесь меня и ломает, что calll сообщением переводят

хз кто так переводит....

call - вызов, а сообщения это про message passing - идея которая есть из всех языков только в эрланге

(смолтак мертв так что не считается и там это больше на вызов походит)

"Вызов" и "событие" это разновидности сообщений, которые в свою очередь являются более абстрактной сущностью

аааа... туда вызов метода, но с сообщением?

Проблема акторов в том что в них всё генерализовано и их сложно представить без упрощений)

аааа... туда вызов метода, но с сообщением?

нет методов

Посоветуете подкасты по пхп и программированию в целом плз

Посмотрите видео из списка https://oopru.github.io/

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

это смущает

Сообщения

Перестань вкладывать в них смысл)

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

аналогия - компьютерная сеть

а когда это описывали обычные с сегодняшнего времени, методы были?

а когда это описывали обычные с сегодняшнего времени, методы были?

конечно были

симмула, алгог - по сути там были методы

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

все что приписывают ООП в плане терминологии (классы, методы, объекты) было до того как термин ООП появился

по сути? но не в привычном нам понимании?

почему? метод это ничто иное как процедура

ну и в симмуле (середина 60-х) были и классы и методы

Actor Model это уже где-то 71-ый год, и там свои отсылки

на другие языки (планер)

которые реализовывали схожую концепцию

короче создаешь класс на вход subject на выход observable, и это будет крутой актор?

нет будет херня полная)

не забудь ещё спецификацию как и о чем акторы будут общаться

Актор вообще кстати по одиночке не существует

ну то есть разница, так как я понимаю, в том что smalltalk первых версий, что планнер + влияние проектов ARPA и тд. привели к тому что у людей возникли идеи децентрализованных систем. А вот то что мы сегодня имеем в большинстве своем - старые добрые наследники идей первых языков вроде алгога, централизованные (единый центр - main рутина)

почему? туда сообщения, там слияние и очереди на выходе

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

это да, тогда таск или действиее

а методов в акторе не вообще? там сигналы?

или компонуется цепочка при помощи спецификации?

спецификация же работает с коммандой и тасками?

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

у вас столько знаний писали бы статьи об акторах и публики их на обсуждение

спецификация же работает с коммандой и тасками?

http://dist-prog-book.com/chapter/3/message-passing.html

Тема довольно объёмная, одних интерпретаций понятия вон сколько)

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

время ни у кого нет, но вы спрашивайте, даже я немного в этом могу помочь

только сразу уточните что за приложение и какие данные, точнее это просто инфа или данные предметной области

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

Так ты ничего конкретного не сказал, тебе ничего конкретного и не ответили

Так ты ничего конкретного не сказал, тебе ничего конкретного и не ответили

это концепция этого чата)

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

Ну мол, давайте код

И будем его конкретно мучать)

но каждый раз откладывается что-то и это что-то

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

это результат нашей культуры. нам нужно менять культуру. но это большая тема. не многие готовы

я хотел бы поговорить про модели если не сложно

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

где-то удобнее WHERE фильтровать, где-то сначала inner join сделать

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

Так ты ничего конкретного не сказал, тебе ничего конкретного и не ответили

я вчера описал ситуацию, никто из тех кто учил ничего конкретного по архитектуре не сказал, по тому что я упомянул в сообщении

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

пришло ощущение что разбивать нужно сам запрос, используя ORM-ку

function withCity($stmt) { return $stmt->addWhere()->orderBy(); }

но как правильно это организовывать чтобы голова отпустила, есть у кого мнение?

но как правильно это организовывать чтобы голова отпустила, есть у кого мнение?

Есть паттерн "Specification" и паттерн "Criteria"

я в основном использую паттерн Criteria

но как правильно это организовывать чтобы голова отпустила, есть у кого мнение?

А что есть общего и чем отличаются запросы? Можо определить линию сборки запроса?

ну да я понял как разрабы додумались до AR

active-record

я в основном использую паттерн Criteria

Например: CountryCriteria: public $id public $code; public $name; public $zip; public $zipIsNull; public $orderBy; public $offset; public $limit; CountryCriteriaMatcher: public function getResult(CountryCriteria) public function getArrayResult(CountryCriteria) public function getCount(CountryCriteria) public function getIds(CountryCriteria)

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

вот и появилось слово Model

состоящее из кучи разных реализаций - репозиторий туда, критерию туда, комманд-квери сепаратор туда

и вот такое что-то вышло - назвали модель

Елнур - про второй класс интересно - как его понимать?

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

а потом пишешь запрос от этих полей верно?

ну и потом получается как... если у меня на вход 4 параметра пришло заполненных - запрос один будет. 3 пришло - уже попроще будет

формально говоря я пришел к тому что ты называешь Критерия

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

Пример использования: $matcher = new CountryCriteriaMatcher($entityManager); $criteria = new CountryCriteria $criteria->city = 1; $criteria->zipIsNull = false; $count = $matcher->getCount($criteria); $criteria->orderBy = 'code'; $criteria->limit = 10; $countries = $matcher->getArrayResult($criteria);

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

ну это я понимаю

отдельно count запрос, отдельно result

но в одном файле что удобно

спасибо

а что делать с самим result запросом

в контексте реляционной базы

а внутри CountryCriteriaMatcher - могут быть свои приватные функции, которые собирают запрос

со связами и джоинами

его то как разбивать

воот это мне и интересно

как его бьют чтобы умно получалось

а внутри CountryCriteriaMatcher - могут быть свои приватные функции, которые собирают запрос

или лично я создаю AbstractCriteriaMatcher, где есть вспомогательные функции

шо такое у вас ЭнтитиМенеджер?

типичный DI?

ну типа - дай синглтон - на держи?