Pull to refresh
145
0
Никита Нефедов @nikita2206

User

Send message
То же самое можно сделать не используя бандлы, в чём аргумент?

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


Я прямо таки откровенно не понял.


Попробуй теперь перевезти свой код из папочки `src/` на другой фреймворк. Там не просто какой-нибудь слой адаптеров поправить, там придется перелопатить иерархию директорий. Если есть желание разбить два компонента — один для работы с юзерами и один для работы с платежами, ничего не мешает это сделать просто вынеся их в разные директории, для этого не нужны разные бандлы.
Расширение можно делать очень просто — изменяя код. В случае с third-party библиотеками ты не можешь менять их код, поэтому прибегают к разным подходам, в т.ч. к ивент-модели. Но когда ты можешь менять код и этот код не будет работать вне твоего приложения, нужно делать наиболее прямо.
Уровень предстваления твоего приложения входит в рамки твоего приложения. События привязывают тебя к symfony/event-dispatcher, сервис ни к чему тебя не привязывает, а контроллер это адаптер.
Идея бандлов нужна только для распространения кода, а не для конкретного приложения. Бизнес логика самого приложения вообще не должна быть в каком-либо бандле, иначе ты как раз увеличиваешь связанность своей бизнес-логики с фреймворком symfony2
Ну, объект — он и хранит состояние, не ф-я.
2) — через имя класса, из которого хотите вытащить статический метод. parent:: работает только в контексте вызова метода объекта
Вот здесь хорошее объяснение как использовать либпазл для индексирования изображений stackoverflow.com/a/9780314/1461092
Скорее всего так и останется как есть. Оппозиция была очень сильная против строгой типизации даже в том варианте, в котором ее получилось протолкнуть, по-умолчанию такого точно не будет в пхп.
Там речь про int -> float, это конверсия без потери (в этом и суть widening-а), а float -> int не разрешен
Текущий вариант, позволяет не библиотеке определять, должен ли ты преобразовывать данные вручную или они сконвертятся на лету. Вместо этого вызывающий код решает по каким правилам ему работать, выглядит куда более гибко и не создает проблем тем кто любит автоматическую конвертацию типов.

Я лично вижу лучший вариант только просто строгие типы, но это за гранью возможного.
Добавьте апдейт, что STH Dual Mode был принят, драма из овер.
Ну JIT-а не будет на уровне языка пока что. То, что они открыли, это не JIT, это сложно как-то назвать вообще. Нормальный жит возможно будет позже, либо в 7.1, либо в виде экстеншена.
Да пишите вы код который легко читать и работает, а не оптимизированный. Оптимизировать надо архитектуру, а не вызовы array_key_exists
Это относится только к функциям которые используют зпп, то есть функции в расширениях (не в пхп коде) и ускорение там совсем небольшое будет, там больше времени съедается на других вещах. Но вообще в 7 уже довольно хорошо ускорили вызов функций.

Кстати эта рфц должна быть уже в апстриме, так что это уже не планы :)
FYI В PHP7 strlen и еще пара горячих функций были вынесены в отдельный опкод, так что это технически больше не вызов функции, а медленнее из-за `> 49`
Да с этого, по сути, надо было начинать, в свете перехода на майисам
По-моему это как раз уязвимость именно баша — посмотрите на репродьюсер: env X="() { :;}; echo busted" bash -c «echo stuff»

Он начинает испольнять строковый литерал. Может это на самом деле нормальное поведение для баша, но обычно даже самые динамично-высоко-уровневые языки не исполняют строки если их не просить.
1
23 ...

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity