А в чем трудность? Работодатель пишет документ о внутреннем распорядке, в котором указывает, что сотрудники, кроме SMM, не должны пользоваться перечисленными соц.сетями. Затем сотрудник подписывается, что ознакомлен с приказом о новом распорядке. А дальше дело техники, устное предупреждение -> письменное предупреждение -> выговор и т.д. После серии выговоров, уже есть основание для увольнения. В любом случае, человек либо перестанет сидеть в СС (просто чтобы нервы не трепать себе с объяснительными), либо уйдет в другое место.
Думаю создать искусственный интеллект (ИИ), в том виде, в каком его на самом деле хочет человечество, невозможно логически.
Ведь мы хотим создать не соперника человека (только умнее и сильнее), а умную коробочку, которая сможет мыслить абстрактно и анализировать как человек, но при этом с определенными ограничениями, иначе машина вполне справедливо может прийти к выводу, что больше всего несчастий у человечества было от него же самого (нет, это не фантастика, посмотрите на историю мира через призму холодного логического анализа).
А теперь давайте подумаем можно ли создать абстрактное мышление с какими-либо ограничениями?
Нет, нельзя, потому что абстрактное мышление — это по определению открытый граф, со множеством пересечений, параллельных ветвей и обратными циклами (иногда зацикливанием), когда мы ищем решение неизвестной задачи, мы знаем только стартовую точку (и та в ходе решения тоже может смещаться), но где кончится граф, какой путь при этом будет создан — не знаем, в противном случае — это уже алгоритм решения известной задачи.
Получается мы хотим создать ИИ, который будет умный — но не очень, абстрактный — но по нашему алгоритму. Не получится.
А как это увязывается с юридической стороной вопроса? Не дай бог, произошла авария, приходят ребята в синих пиджаках, поднимают договора или акты на ремонт (профилактику) и говорят: «а что это у вас он год не обслуживался? Какие графики?»
Как по мне использование аннотаций в phpdoc для таких критичных вещей как кеширование или логирование, проверка аунтефикации пользователей и т.д. это не слишком хорошая идея. Как минимум этот код невозможно будет прогнать через анализаторы, повышается вероятность ошибок и т.д.
Согласен на 1000%, не понимаю откуда пошла такая мода писать бинес-логику в комментариях, Обфускацию кода не сделаешь, с opcache разных производителей бывают проблемы (opcache.save_comments и opcache.load_comments) ну и Reflection использовать в каждом запросе на нагруженных проектах — очень сомнительная вещь.
Если же делать правильный прокси или декоратор чтобы его можно было подсунуть вместо оригинального класса, то это потребует генерацию однотипного кода для каждого кэшируемого метода, а в случае с прокси, еще и для всех методов.
Зачем? в этой статье как раз приводится работающий пример, который опровергает это утверждение.
С типом — да, если у вас производится где-то проверка типа, прокси придется наследовать от реального объекта. Но здесь есть два но: во-первых, далеко не всегда есть проблема с проверкой типа, например, когда вы создаете локальную переменную, которая уничтожается, сразу после выхода из метода, обернуть её универсальным прокси быстро и удобно. Во-вторых, если проверка типа всё таки имеется, то как правило проверяется не конкретный тип, а базовый и опять же надо сделать всего один класс прокси наследующий — наследующий от базового типа.
Также остается вопрос с тем, что такие прокси надо обновлять при добавлении новых методов
не надо! в этом и был смысл статьи, в PHP для этого есть магический метод __call()
Более того, делать кэширование и логирование правильно с помощью АОП,
Мэтт Зандстра описывает, как использовать для этого Decorator.
извините, но просто з… ли уже, страна уже несколько лет стреляет техногенками, одна хуже другой, то метро, то самолеты, но интернет это конечно самое главное, вот его «починим» все зашибись станет.
Если у вас в контроллере нужно часто решать — использовать кэш или нет, то давайте рассмотрим вашу задачу подробнее — мне в голову не приходит зачем это может быть нужно.
это не конкретный реальный проект, сборки из разных опытов.
Если для конкретики, например, есть CMS frontend и backend, которой используют один слой модели (коробочное решение, залил на хостинг и работает) при этом frontend должен работать через кэш, а backend с живыми данными, как в этом случае быть?
они схожи между собой, три шаблона: адаптер, декоратор и прокси. Общая идея — выступить контейнером для реального объекта, а дальше, адаптер — транслирует один интерфейс в другой, декоратор — добавляет новую функциональность без наследования, а прокси сохраняет интерфейс, но между вызовами делает что-то ещё, кэширует, контролирует доступ и т.д.
По факту, за счет магического метода __call() интерфейс прокси будет автоматически совпадать с реальным объектом. Но проблема может быть в том, что $news в нашем примере стал объектом другого типа, и если где-то в коде есть проверки типа (например instanceof или тип данных в параметрах метода), то эти проверки сломаются. Чтобы этого избежать надо просто наследовать \Cache\Proxy от \Storage, разумеется универсальность класса в этом случае снизится.
хорошо, будет совокупность классов в слое модели, и они будут знать о формах и реквестах?
может тогда лучше логику сохранения в форме сделать (был такой вариант)?
в любом случае чтобы все заработало вместе, должен быть класс, который будет знать и о модели, и о форме, и о реквесте.
это да, но где тогда размещать эту логику? в модели тоже не правильно — она не должна знать ни о формах, ни о реквестах, получается отдельный класс как тут habrahabr.ru/post/213971/#comment_7362351
Ведь мы хотим создать не соперника человека (только умнее и сильнее), а умную коробочку, которая сможет мыслить абстрактно и анализировать как человек, но при этом с определенными ограничениями, иначе машина вполне справедливо может прийти к выводу, что больше всего несчастий у человечества было от него же самого (нет, это не фантастика, посмотрите на историю мира через призму холодного логического анализа).
А теперь давайте подумаем можно ли создать абстрактное мышление с какими-либо ограничениями?
Нет, нельзя, потому что абстрактное мышление — это по определению открытый граф, со множеством пересечений, параллельных ветвей и обратными циклами (иногда зацикливанием), когда мы ищем решение неизвестной задачи, мы знаем только стартовую точку (и та в ходе решения тоже может смещаться), но где кончится граф, какой путь при этом будет создан — не знаем, в противном случае — это уже алгоритм решения известной задачи.
Получается мы хотим создать ИИ, который будет умный — но не очень, абстрактный — но по нашему алгоритму. Не получится.
Согласен на 1000%, не понимаю откуда пошла такая мода писать бинес-логику в комментариях, Обфускацию кода не сделаешь, с opcache разных производителей бывают проблемы (opcache.save_comments и opcache.load_comments) ну и Reflection использовать в каждом запросе на нагруженных проектах — очень сомнительная вещь.
С типом — да, если у вас производится где-то проверка типа, прокси придется наследовать от реального объекта. Но здесь есть два но: во-первых, далеко не всегда есть проблема с проверкой типа, например, когда вы создаете локальную переменную, которая уничтожается, сразу после выхода из метода, обернуть её универсальным прокси быстро и удобно. Во-вторых, если проверка типа всё таки имеется, то как правило проверяется не конкретный тип, а базовый и опять же надо сделать всего один класс прокси наследующий — наследующий от базового типа.
не надо! в этом и был смысл статьи, в PHP для этого есть магический метод __call()
Мэтт Зандстра описывает, как использовать для этого Decorator.
это не конкретный реальный проект, сборки из разных опытов.
Если для конкретики, например, есть CMS frontend и backend, которой используют один слой модели (коробочное решение, залил на хостинг и работает) при этом frontend должен работать через кэш, а backend с живыми данными, как в этом случае быть?
но тогда мы лишаемся возможности обратиться к живым данным минуя кэш?
может тогда лучше логику сохранения в форме сделать (был такой вариант)?
в любом случае чтобы все заработало вместе, должен быть класс, который будет знать и о модели, и о форме, и о реквесте.