Pull to refresh

Comments 44

ну default конструкторы сразу реджектнут, ибо:
it is highly improbably somebody's code relies on being unable to call parent::__construct.

весьма наивно. Более того, автор приводит в RFC ссылку на реализацию дефолтных конструкторов в c# и в Java, при том что ничего общего с предложенным там нет. В том же c# если у класса нет подходящего конструктора вызывается пустой дефолтный конструктор. А автор RFC предлагает дергать все конструкторы по цепочке наследования.

«стандартизированные интерфейсы» для Http так же думаю реджектнут и хорошо. Зачем вообще это включать в PHP, тот же PSR-6 еще в драфте и не собирается оттуда выходить. Так зачем очередной велосипед да еще и на уровне ядра…

С фильтрацией при unserialize так же не все так красиво. Хотя из этих трех эта RFC хоть выглядит полезной.
> ну default конструкторы сразу реджектнут, ибо:
И это хреново, сейчас всегда надо проверять проверять чтобы у родителя был этот метод (из-за этого я всегда добавляю пустые конструкторы во все создаваемые классы).

> А автор RFC предлагает дергать все конструкторы по цепочке наследования.
Что-то никак не могу припомнить ни одного случая когда было нужно сознательно разорвать цепочку вызова конструкторов, а вы?
Что-то я погорячился. Внимательно изучив RFC всетаки речь именно о конструкторах по умолчанию. Меня видимо смустила как раз таки эта фраза из BC changes (там говорится все же о том что «крайне маловероятно что чей-то код работает за счет того что нельзя вызывать конструктор у родителя, если его нет»). Если все так то у этой RFC неплохие шансы и действительно не вижу ничего плохого в оной. С остальными мнение не поменял.

Что до разрыва вызова цепочки конструкторов — самый распространенный пример — прокси классы для ленивой инициализации сервисов, реализация сущностей доктрины и т.д. У них у всех отключен конструктор родителя. Сам я разрывал цепочку вызова конструкторов для случаев когда автор базовых классов делал в оных что-то сверхестественное, например к файловой системе обращался или в базу лез.
>> Что-то никак не могу припомнить ни одного случая когда было нужно сознательно разорвать цепочку вызова конструкторов, а вы?

Когда в конструкторы понатыкают тяжелых операций
А если это необходимо для правильной инициализации объекта?
Типичный конструктор выглядит примерно вот так:

function __construct($a, $b, $c)
{
// Сначала присваиваем переданные переменные свойствам класса
$this->a = $a;
$this->b = $b;
$this->c = $c;

// Делаем еще какие-то операции

}

Почему бы не вынести все что там дальше делается в отдельный метод init или connect. Кому надо, тот сам вызовет его дополнительно руками. Зато ваш класс можно использовать для ленивой инициализации.

Да, теперь класс инициализируется двумя строчками вместо одной. Но если есть IoC, вы легко рефакторите весь код.
> Почему бы не вынести все что там дальше делается в отдельный метод init или connect
Какой в этом смысл если класс физически не может работать без этих данных? Хотя если вам нравится постоянно держать в голове необходимость вызова init сразу после создания экземпляра (= вызова конструктора) — пожалуйста.
Для того что бы не держать в голове можно это на уровне класса делать — по первому требованию дергать init который будет проверять не инициализировал ли он сам себя ранее. Или IoC просить. Но согласитесь, обращаться в I/O в конструкторе это дичь. Допускаю что в некоторых случаях это оправдано но в большинстве случаев лучше так не делать.
> Для того что бы не держать в голове можно

Собственно, я вообще вел к тому что случаи бывают разные и просто так взять и сказать «должна» нельзя (везде есть свои недостатки/достоинства, поэтому все больше зависит от личных предпочтений и принятых соглашений)

> Допускаю что в некоторых случаях это оправдано но в большинстве случаев лучше так не делать.

Соглашусь с тем что надо по месту смотреть, где это будет говнокодом, а где-то вполне уместно.
Насколько я понял — просто parent::__construct() не будет выкидывать ошибку, если сам метод не определён в родительском классе, вот и всё. Так что RFC имеет все шансы пройти.
Встречаем Laravel 5 Elixir — В следующей версии Laravel в качестве билд-инструмента предлагается использовать Elixir — надстройку на Gulp, который в свою очередь реализован на JavaScript и требует node.js.


Зачем? Ну зачем нам js еще и в php.
Неужели PHP на столько ущербен, что нельзя написать нормальный билд-инструмент на нем. Я прям возмущен этим решением…
штуки типа autoprefixer, uglifyjs и т.д. вы тоже на PHP будете портировать? Я вот phing на gulp заменил на своих проектах и счастлив. Можно распаралелить сборку настолько насколько это возможно и при этом это не ущербно выглядит. Каждому свое словом.
Во первых: перечисленные вами штуки это из мира JS, и больше востребованы там или для front-end.
Во вторых: они уже портированы

1) autoprefixer-php
2) makesites/uglifyjs-php, smallhadroncollider/uglify-php

В третьих: я php программист, я пишу на php, а не на js, и я не люблю js в принципе.

Почему меня обязывают использовать js инструменты в php фреймворке? Именно этим я и возмущен. Минус Laravel-у.
Вас не обязывают. Вам рекомендуют. Более того вот эта штука как раз таки и была создана что бы вы могли пользоваться чудным миром фронтэнд-штуковин и не писать кучу JS кода.

Что до приведенных вами ссылок:
— autoprefixer-php — внезапно требует nodejs, по сути это просто обертка над proc_open.
— makesites/uglifyjs-php — тут интереснее, node.js нам уже не нужен что бы работать но сделано это за счет того что node.js установлен на серере у этого самого makesites и просто обрабатывает http запросы формируемые этой либой. Идея занятная но мы таким образом делаем себя зависимыми от его сервиса который может попросту в один прекрасный день перстать быть доступным.
— smallhadroncollider/uglify-php — работает на exec, то есть еще хуже ситуация чем с autoprefixer.

Отдельная же реализация требует огромного вложения сил при довольно сомнительном профите. Проще поставить один пакет в систему.

Я не знаю почему у вас так много ненависти в отношении JS или node.js. Меня вот совсем не напрягает, это капля в море по сравнению с тем зверинцем технологий которые я ипользую в повседневной работе. Благо есть ansible и vagrant что бы все это разруливать.
Если кому интересно, на одной из конференций был доклад Optimising Your Front End Workflow With Symfony, Twig, Bower and Gulp. К сожалению видео я больше не могу найти, остались только слайды и пример структуры проекта, если у кого-то имеется ссылка было бы неплохо поделиться.
Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.
— С просторов интернета

*Точнее с просторов сообщества habrahabr во вконтактике
Плюсую. Именно по этому написал пакет, который умеет собирать ассеты без каких либо внешних зависимостей: github.com/SerafimArts/Asset (ридми: github.com/SerafimArts/Asset/wiki/%5BRU%5D-README)

Вполне себе уже работает в продакшене, единственное но — пока минимизация не реализована.
А Assetic не рассматривали? В целом… я не понимаю зачем нужно переписывать что-то что работает и хорошо, при этом делать реализацию заведомо медленнее и тратить время на поддержку оной. Мы ведь боремся за секунды времени сборки проекта.
И да, как вы решаете вопрос с внедрением всего этого добра в шаблоны, есть ли разделение на окружения, планируются ли сорсмэпы?
1) Это же тупо функции\методы, о какой конкретно поддержке вы говорите? о_0

2) Есть файл конфигов, где можно настроить всё, что пожелается (я очень надеюсь): github.com/SerafimArts/Asset/blob/master/src/config/config.php

3) На счёт сорсмапов — план разработки пока следующий: github.com/SerafimArts/Asset/wiki/TODO но я уже смотрел спецификацию в надежде быстренько запилить, как можно заметить — быстренько не получилось — надо вникать.
Он слишком тяжеловесен, имхо. И не думаю, что медленнее. т.к. в продакшн-режиме просто происходит проверка существования кеша и всё, без проверок изменений файлов и прочего. В дев-режиме же каждый файл кешируется отдельно, что избавляет от дополнительных телодвижений.
Нет ну дело вы большое делаете, просто у меня сомнения по поводу оправданности подобного велосипедостроения (медленно, баги, никто не пользуется и вы через пол года год забьете). Если честно я даже завидую — у меня например нет столько свободного времени.
Я пробовал уже существующие решения, включая вот это: github.com/CodeSleeve/asset-pipeline казалось бы намного надёжнее (звёздочек аж почти 500, и 50 форков), но по факту — багов там одним местом жуй, а предложенное Тейлором (эликсир) — просто не воспринимаю как что-то вменяемое — тупо костыль.

Учитывая то, что моё решение используется на работе вместо компилей из мира nodejs — времени хватает. А на счёт полугода:
Initial commit. 6 Aug 2013
и 400 установок с пакагиста. Тут уж не отвертеться ;)
Медленно, всегда будет отставать от актуальной реализации, куча времени убиваемая на поддержку решения вместо решения реальных проблем коих в PHP комьюнити хватает. Но это мое личное мнение, мне просто это не понятно.

p.s. 400 устновок с пакагиста это мало. У вас небыло такого что вы поставили что-то, покрутили и выкинули?
Ну это всё понятно. Только актуальной реализации не существует из принципа.

А чего такого не хватает php сообществу, без влезания в дебри сишного кода? Всё что в голову приходит — переписывание стандартной библиотеки под ОО вид =)
SPL и так состоит из ОО штук. Если вы про работу со скалярами как с объектами — не вижу в этом смысла. С тем синтаксисом который используется в PHP для доступа к методам/свойствам уж лучше как функции использовать.
А почему только Laravel? :(
Вначале был отдельный пакет, но потом, вместе с рефакторингом всего и вся — прицепились пакеты кеширования и конфигов от лары, так что для того, что бы вытащить всё это из под его крыла — надо как минимум запилить фоллбеки для всех illuminate/* пакетов: github.com/SerafimArts/Asset/blob/master/composer.json#L12
Ну и плюс смысл был в том, чтобы реализовать что-то аналогичное рельсовому ассет пайплаину (манифесты получились покруче, имхо), только для себя.

Просто пакет поставить, добавить провайдер и пользуйся на здоровье, прямо из коробки любой транслятор, который вызывается одной строкой без всякого геморроя в настройках и сборки всего этого, всё автоматом.
да, схожесть с asset pipeline я уловил )
но тем не менее, РНР сообщество движется к унификации экосистемы, и было б круто, если б ваш пакет можно было использовать во всех популярных фреймворках. А я бы попробовал написать к нему таски для Robo Task Runner
Попробую как-нибудь на досуге сделать адаптеры для существующих готовых решений.
Да, я вот Zend2 использую, хочется чтобы пакеты ставились на любой фреймворк, как например kriswallsmith/assetic.
Да тяжелый, да может есть не все ф-ии, которые нужны, но я могу поставить его на любой фреймворк. Это большой плюс.
А я вот такую штуку для себя написал в качестве эксперимента. (https://github.com/Freezko/smart-assets) Правда только для laravel 4.
Основан на github.com/CodeSleeve/asset-pipeline
Отличие в том что в шаблоне сразу пишем ссылку на скрипт который нам необходимо преобразовать, но через дополнительный route.
<script type="text/javascript" src="/pipeline/folder/file.coffee"></script>
— в данном случае /pipeline указывает на то что файл необходимо конвертировать.
Минификация и конкатенация в один файл тоже есть.
Но в продакшене не использую пока. Нашли багу в sass-php. Он не может bourbon адекватно преобразовать. Падает с ошибками. (Например ошибка о том что else-if не может быть после else, а у бурбона встречается внутри такая проблема. Grunt при этом не ругается)
Кодеслив и так при вызове функции создаёт роут и конвертит всё налету. Как раз именно такой, какой у вас в примере, так что берёте и заменяете обратно на CodeSleeve — будет тоже самое. ( github.com/CodeSleeve/asset-pipeline/blob/master/src/routes.php )

Плюс заходим сюда и смотрим версию scss: github.com/Freezko/smart-assets/blob/master/composer.json она 0.0.9, а актуальная 0.1.1. Как бы всё становится на свои места ;)

Плюс версией от CodeSleeve по факту невозможно пользоваться, просто потому, что он компилит каждый scss файл отдельно, как следствие — переменные и миксины из одного файла не будут доступны в другом. Я даже не говорю про объединение, минификацию и генерацию *.gz алиаса.

Яж не просто так решил не брать готовое, а полностью написать своё с нуля, ибо у CodeSleeve слишком много проблем в подходе, исправить которые слишком сложно.
З.Ы. Например результат у моего пакета в продакшене будет вот такой: docs.rudev.org/assets/19abeee936b7dbfb854723b218fd48f9-layout.scss.css для вот этих стилей: github.com/Developers-RuDev/Docs/tree/master/app/assets/stylesheets и вот таким подключением github.com/Developers-RuDev/Docs/blob/master/app/views/layouts/master.blade.php
По поводу scss. Я взял composer.json от codesleeve. Каюсь не посмотрел актуальные версии пакетов.
А вот по поводу routes у codesleeve не согласен. Я даже поэкспериментировал. Он в этот route не попадает если написать путь к файлу — /assets/folder/file.coffee. Во всяком случае преобразования файла не происходит. Как я понимаю codesleeve написали аналог рубишного asset-pipeline. А это совсем не то что написал я.
Хм, не знал что не будет работать если прописать прямой путь. В таком случае беру свои слова обратно на счёт бессмысленности.

В любом случае это не отменяет остальных проблем.
Спасибо Вам за еще одну интересную подборку!
Как и всегда — огромное спасибо!
Самому постоянно все отслеживать ну просто не реально, а тут все по полочкам и в тему!
Sign up to leave a comment.