Flying

Примерно 300кб сам фреймворк и роутинг. Если динамики почти нет - зачем вообще не тащить фреймворк? Можно посмотреть на svelte

Как вариант, можно вынести только проверку в отдельный сервис в доменном слое (Domain Layer), и этот сервис передавать как аргумент в метод add() вашей сущности. Если этот сервис бросит исключение, то метод add прекращает выполнение. В сервис передавать в конструкторе репозиторий или другой объект, который подгрузит необходимые для проверки данные.

Далее вынести вызов метода add() в сервис на уровне приложения (Application Layer), как вы написали, в котором и передавать ранее созданный сервис проверки в метод add().

В такой реализации вам всегда будет необходим этот доменный сервис, и вызвать метод add() без него не получится.

Пример:

class Entity
{
	public function add(ComplexEntityValidator $validator) {
		$validator->validate();
	}
}

class ComplexEntityValidator
{
	public function __construct(EntityRepository $repository) {

	}

	public function validate() {
		// проверка
	}
}

class EntityApplicationService
{
	public function __construct(ComplexEntityValidator $validator) {

	}

	public function __invoke() {
		$entity = new Entity();
		$entity->add($validator);
		// сохранение сущности
	}
}

Вопрос одновременно дебильный и нормальный.
Автор просто не может нормально словами написать, чего хочет.
Для современного поколения, воспитанного ютубой, это нормально.
Если бы вопрос можно было задать с помощью слов "гы-гы", "круто, чувак" и смайликов, то у него бы все получилось.
А пока приходится использовать интеллект на принимающей стороне, чтобы понять, что он там мычит.

А мычит он не про сам шелл, а про используемый в нем скриптовый язык.
И ответ получается очень простой - для некоторых задач Bash scripting language тупо подходит лучше. Не говоря уже про интеграцию скриптового языка баш в командную оболочку баш, какой никогда не добиться с помощью "обёрток".

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

Так что да - или легаси, или тупо адекватность задаче.

Апд. В ходе этой дискуссии я сообразил одну очень важную вещь. Язык программирования по определению является вторичным по отношению к командной оболочке. Главное в баше - это все-таки возможность запускать команды и позволять им взаимодействовать друг с другом. А язык уже построен вокруг этой основной задачи. Если вы попытаетесь вкрячить этот функционал в какой-то из языков программирования общего назначения, вы испортите и оболочку, и язык.

Насколько я понимаю раньше шеллы использовались в качестве примитивных высокоуровневых языков. Сейчас у нас есть Perl, Python, nodejs, php...

Ну давайте вместо рабочего стола пользователю дадим сразу Visual Studio, ведь какая разница как программу запускать - иконкой на рабочем столе, или форкать из высокоуровневого языка?

shell - это оболочка операционной системы. То, что кроме графической есть еще и command line interface - это совершенно нормально и адекватно. И шелл позволяет пользователю и администратору работать в операционной системе гораздо удобнее, чем через язык программирования.

То, что sh/bash и другие, настолько развиты что сами по себе являются неплохими языками программирования - это просто следствие того, что командый интерфейс и создавался тогда, когда каждый пользователь был немного программистом, и следствие того, что cmd line удобен для автоматизации просто по своей архитектуре.
Поэтому Powershell, bash/zsh/ksh будут продолжать развиваться.

Но ты можешь попробовать писать всю автоматизацию на любом другом языке программирования. И со временем немного столкнуться с тем, что скрипт, написанный на шелл 10 лет назад - просто работает, а скрипт написанный на питон 10 лет назад - несовместим.

Его выпилили очень давно в PHP 5.4.0.. Переписывайте код.

Потому что нужно не слушать учителя, надеясь что он даст тебе знания, а брать их самому, читая учебник (документацию) и нарабатывая практику (решая задачки). Учитель только так, считай "онлайн курсы", и может помочь с конкретными вопросами, типа "вот задача, я попробовал ее решить вот так и вот так, но что-то не выходит, где ошибка", а не "я тут ничего не понимаю, как?"

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

Абстрактный контроллер реализует Service Subscriber. Вам достаточно туда добавить ваш Setting:

abstract class Controller extends AbstractController
{
    public static function getSubscribedServices()
    {
        return array_merge(parent::getSubscribedServices(), [
            'setting' => Setting::class,
        ]);
    }

    protected function getSetting(): Setting
    {
        return $this->get('setting');
    }
}

Лучше найдите нормального специалиста. Он вам и подскажет какой стек выбрать, и какие плюсы и минусы вас ждут. Не будьте плохим работодателем - не отсекайте себе потенциальных работников.
П.С. Написание такой системы с нуля влетит в копеечку. Лучше все-таки присмотреться к готовым решениям и, в случае чего, нанять спецов немного подрихтовать систему.

Посмотрите на mcedit, входит в состав mc.

правки бывают двух типов:
1. исправление косяков.
2. дополнительные фичи/изменение уже реализованных.

1 делается бесплатно и как можно быстрее.
2 делается за отдельные деньги. или не делается вообще и работа с клиентом прекращается.

есть ещё 3: дать клиенту скидобан на конкретно оговоренный объем дополнительных работ.

это из основного. есть ещё методы, но они уже для постоянных клиентов.

спросите у многих, кто это говорит.

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

лично я для web–дев/бэкэнд предпочитаю слоника.

Абстрактный класс нужен для того, чтобы не было возможности создавать его экземпляры, а только его классов-наследников.
Простой пример. Пусть у нас будет абстрактный класс Фигура с методом Нарисовать; и есть его классы-наследники Круг и Квадрат.
Так вот. Экземпляры классов Круг и Квадрат мы имеем право создавать, а вот экземпляр Фигуры создавать не имеем права, т.к. это не имеет физического смысла. И уж тем более мы никак не можем реализовать метод Нарисовать у Фигуры. Поэтому и сделан такой запрет на абстрактные классы.
Это необходимо, чтобы код был надёжным и защищённым от кривых рук других программистов

Коротко о разрушаемости в Noita излагается в презентации разработчиков на GDC.
Детальное описание разрушаемости в Jelly in the sky от автора игры: [1], [2], [3].

В Червяках же реализация разрушаемости довольно простая.
Мат. модель уровня состоит из битовой матрицы (где поднятый бит является заполненным, а снятый - пустым), и набора функций рисования в этой матрице. В этой битовой матрице изначально генерируется уровень и эта битовая матрица модифицируется в процессе игры. Функции рисования являются стандартными - это рисование линии от точки и до точки с заданной шириной, а так же рисование залитой окружности. Само рисование происходит нулевыми битами.
По своей сути Червяки являются таким замысловатым редактором для рисования.

Может быть она уже нашли специалиста и проводить ваше code review уже было накладно.


Например стучится на эту вакансию 100+ человек, каждый высылает по тестовому заданию.

Факторы: скорость выполнения, адекватность собеседника, личные предпочтения. Какой-то фактор сыграл не в вашу пользу, и скорее всего вы отсеялись на уровне - "так, тех. задание выполнил, но Вася Пупкин из саратова сделал на 2 часа быстрее, + понравился HR или тех. лиду".

Итог: не расстраивайтесь, выполнять code review каждому потенциальному кандидату - это деньги, и время. Не все компании готовы выливать излишек.

PS: у нас на позицию джуна в прошлом месяце пришло 320 резюме + тех.задание, на 150м резюме мы остановились, условно мы нашли всех кандидатов, остальные 170 остались в недоумении скорее всего. Таков бизнес :)

Потому что $count это не ограничение на количество замен, а туда записывается сколько раз сработала замена.

Потому туда надо передавать переменную, а не цифру.

sandbox.onlinephpfunctions.com/code/87f0105ff5614c...

str_replace(
    array|string $search,
    array|string $replace,
    string|array $subject,
    int &$count = null
): string|array

https://www.php.net/manual/ru/function.str-replace.php

Простой в реализации метод: держите отрезки в каждом элементе отсортированными и непересекающимеся (если два отрезка пересекаются - объедените их).

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

Если же список очень длинный, а ответ ожидается маленький, то есть более быстрый метод. Но он сложный в реализации. Нужно реализовать персистентное дерево поиска. Можно его реализовать на основе персистентного дерева отрезков. Это такая структура, в которую можно добавлять элементы, и удалять их за O(log n). Также можно обходить все элементы за O(log n + (их количество)). Кроме того, сохраняются все версии дерева после каждой операции и общее количество памяти будет O(к log n), где к - количество операций.

Эта структура будет использоватся для хранения предподсчитанных ответов. Если все ваши отрезки нарисовать на одной прямой, то она разобъется на O(n) отрезков, все точки которого будут давать один и тот же ответ при запросе. Мы эти все ответы компактно сохраним.

Используем метод сканирующей прямой. Нанесите все границы всех отрезков на одну прямую, пометив их как начало или конец (и какому элементу списка они соответствуют). Если пройтись по этой прямой слева на право, то будут происходить события - отрезки откроются (новый элемент добавляется в ответ) или отрезки закроются (элемент из ответа удалится). Поддерживая текущий ответ в персистентной структуре мы сильно экономим память. Удобно в качестве начал отрезка брать их координаты, а в качестве конца - координаты концов+1. В таком виде все границы отрезков будут точками, а не числами.

Итак, создайте массив из структур {координата, это начало или конец, номер элемента}. Отсортируйте по координате, потом по флагу начала. Потом пройдитесь по ней и при обработке начала отрезка - добавляйте номер элемента в персистентное дерево. При обработке конца - удаляйте элемент из дерева. Так же перед обработкой каждого элемента запишите в массив-ответ: {предыдущая координата, текущая координата, ссылка на текущую версию персистентного дерева}, если предыдущая координата строго меньше текущей. Этот массив-ответ будет хранить все возможные отрезки с различными наборами ответов в виде {координата начала, координата конца, ответ}.

Когда вы этот массив ответов предподсчитали, можно обрабатывать запросы - Найдите в массиве бинпоиском тот отрезок, которому текущая точка-запрос принадлежит. Вам надо бинпоиском найти самый правый отрезок, у которого начало меньше-равно числа-запроса. Потом проверьте, что координата конца строго больше запроса. В этом случае выводите в ответ обход персистентного дерева по известной версии.

Это решение требует O(n log n) памяти (где n - количество всех отрезков) и O(n log n) времени на предподсчет и O( log n + (ответ)) времени на обработку ответа.

Более простое решение, где ответы считаются так же сканирующей прямой, но сохраняются просто в виде списков, а не версий персистентного дерева, может требовать O(n^2) памяти. Но будет работать быстрее, конечно.