PHP может стать еще лучше

    PHP слоник для привлечения внимания


    Шутки про PHP — уже отдельный жанр в различных сообществах программистов. Некоторые не любят PHP, потому что {lang_name} намного лучше. А кого-то он вполне обоснованно расстраивает.


    Я же PHP люблю. Не смотря на его косяки. Этот язык был создан для конкретной цели и решает он свою задачу хорошо. Схема "принял — обработал — отдал — умер" очень эффективна и решает проблему небольших утечек памяти.


    В моей работе PHP используется постоянно. Так сказать, это основной backend язык, используемый в моих проектах. За время работы у меня появились некоторые пожелания и замечания. Решил поделиться с обществом. Кому интересно, добро пожаловать под кат.


    Традиционный дисклеймер
    Этот пост вряд ли изменит мир. Да и не об этом он. Пост, скорее, о наболевшем. Много субъективных моментов из разряда "я так считаю" или "я так хочу". Предупреждаю заранее, чтобы все были готовы.

    1. Неявное временное преобразование примитива в объект


    Проще объяснить на примере. В JavaScript мы можем обращаться к строке и массиву как к объекту.


    let str = "1,2,3";
    
    let arr = str.split(",");
    
    arr = arr.map(_ => _ * 2);
    
    console.log(arr); // [2, 4, 6]

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


    В JavaScript, насколько мне это известно, массив уже является полноценным объектом, а строка хранится в виде примитива. И при необходимости, строка преобразуется в объект String, происходит вызов необходимого метода.


    Почему бы в PHP не сделать что-то похожее?


    $str = '1,2,3';
    
    $arr = $str->explode(',');
    
    $arr = $arr->map(function ($i) {
        return $i * 2;
    });
    
    var_dump($arr);
    
    // Или даже так:
    
    $str = '1,2,3';
    
    $arr = $str
        ->explode(',')
        ->map(function ($i) {
            return $i * 2;
        });
    
    var_dump($arr);

    Десятки функций, связанных со строками и массивами можно было бы убрать в классы String и Array. Написание кода в функциональном стиле не был бы столь мучительным процессом.


    $arr->keyExists(...);
    $arr->map(...);
    $arr->filter(...);
    $arr->keys(...);
    $arr->push(...);
    $arr->pop(...);
    $arr->exists(...); // in_array
    
    $str->repeat(...);
    $str->join(...);
    $str->trim(...);
    $str->replace(...);

    Другая сторона этого вопроса: объектная реализация примитивов может имплементировать различные интерфейсы. Что нам это дает? Можно свободно избавляться от таких функций, как is_iterable, is_numeric, is_countable, и переходить на иcпользование instanceof \Countable, \Traversable и п.р. Ну разве не прекрасно?


    2. Дженерики


    Впервые с дженериками я познакомился, когда изучал Java. Мощь дженериков сложно переоценить. Они могут использоваться в DI контейнере, когда указываем тип объекта, который хотим получить:


    $service = $container->get<SomeService>();

    Они полезны при реализации различных коллекций, а также репозиториев (Yii2 Query или Doctrine).


    Еще, какую пользу могли бы принести дженерики, это type hinting массивов объектов (этого уж очень не хватает). Опять же, проще объяснить не примере:


    public function getItems(): Array<Item>
    
    public function setItems(Array<Item>): void

    Выглядит уже инетересно, согласитесь? Теперь и мы уверены, что всегда получим массив объектов определенного класса, и IDE точно знает, что подсказывать без всяких PHPDoc блоков. Но мы ведь можем не только массивы передавать, но и свои коллекции:


    public function getItems(): Collection<Item>
    
    public function setItems(Collection<Item>): void

    Хотя синтаксис массива объектов как PHPDoc мне нравится больше (SomeObject[]), этот вариант тоже хорош. В любом случае это лучше, чем то, что есть сейчас (либо array, либо ничего).


    3. Аннотации или декораторы


    В Java аннотации используются с версии 1.6 (придуманы они были еще раньше). Доступны они через рефлексию. (Java знаю плохо, поэтому исправьте, если где-то не прав)
    В JavaScript существует похожий механизм — декораторы (не уверен, что они являются частью стандарта, но уже повсеместно используются благодаря Babel).
    А что есть в PHP? В PHP есть PHPDoc блоки, которые созданы сугубо для документирования. И разработчики выжимают из этого все, что могут. Примерами служат такие замечательные библиотеки, как Doctrine и PHP-DI.


    Я об аннотациях задумался, когда подключил компонент Symfony Event Dispatcher. Когда я создаю класс-подписчик, который реагирует на события в системе, я должен имплементировать метод getSubscribedEvents, который возвращает массив, где в качестве ключа — идентификатор события, а в качестве значения — имя метода, реагирующего на событие в этом классе. Это простой и эффективный способ решения проблемы. Эффективный, но не удобный. Почему? У меня идентификаторы событий хранятся в константах классов. Если я хочу найти подписчиков на какое-то событие, я произвожу поиск по коду, который использует константу-идентификатор, меня перекидывает в метод getSubscribedEvents, где я беру название метода(ов), и ищу этот метод(ы) в классе. Если мне нужно узнать, на какое событие реагирует какой-либо метод, то мне нужно проделать ровно то же самое, только в обратном порядке. Слишком много шагов для столь простого действия. Опять же, если я хочу переименовать метод-подписчик, я не могу просто взять и воспользоваться возможностями IDE (поиск по тексту — функция редактора, а не IDE). Это придется делать вручную.
    Но как оно могло бы быть, если бы существовали аннотации:


    @EventSubscriber(ItemEvents::CREATE)
    public function itemCreated(ItemEvent $event)

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


    Из плюсов сразу хочется отметить поддержку IDE, если это будет внедрено в язык. Аннотации можно импортировать также, как и обычные классы, что избавляет от необходимости писать namespace'ы.


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


    4. Короткий синтаксис функций.


    До знакомства с JavaScript при любых действиях с массивом (фильтрация, маппинг и п.р.) я использовал императивный подход:


    $input = [...];
    $output = [];
    
    foreach ($input as $i => $item) {
        // logic
        $output[$i] = $item;  
    }

    После изучения ReactJS + Redux мне больше понравился функциональный подход к решению подобных задач:


    let output = input.map(item => {
        // logic
        return item;
    });

    Но мне не нравится, как это выглядит в PHP:


    $output = array_map(function($item) {
        // logic
        return $item;
    }, $input);

    А теперь давайте объединим первую идею с этой:


    $output = $input->map(($item) => {
        // logic
        return $item;
    });

    Вот согласитесь, в PHP не хватает чего-то, что заменило бы function($item) {} на что-то более чистое и эллегантное. И совсем не обязательно, чтобы это что-то отличалось по функционалу от обычной записи (как это есть в JS). Главное, чтобы оно занимало меньше места и не создавало шум для глаз разработчика. Об этом уже говорилось ранее не мной. И даже есть такой RFC. Но это актуально, не так ли?


    5. Асинхронность


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


    В PHP может быть множество задач, которые хотелось бы сделать асинхронно, не дожидаясь окончания выполнения. На ум сразу же приходят работа с большими БД запросами и HTTP запросами. Чтобы составить большой отчет, приходится либо долго ждать, либо пользоваться сторонними решениями, типа очередей. В моем случае, в проекте в большом количестве используются Slack уведомления и Mailgun оповещения. За один клиентский запрос может быть отправлено около десятка HTTP запросов. Почему бы не запустить это все на фоне, а клиенту уже отдать страничку? Это возможно. Но простого решения из коробки нет.


    Знаю про существование расширения PThreads, но насколько это просто решение из коробки? К тому же, это про настоящую многопоточность, которую нужно уметь готовить.


    6. Использование выражений везде


    Например в значениях параметров по умолчанию:


    class Money {
        __constuct($currency = new Currency('RUB')) {...}
    }

    Или даже в свойствах класса:


    class Money {
        private $currency = new Currency('RUB');
    
        public function setCurrency(Currency $currency) {...}
    }

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


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


    class Money {
        private $currency;
    
        __constuct(Currency $currency = null) {
            $this->currency = $currency ?? new Currency('RUB');
        }
    }

    Использование выражений на создании объектов налету не заканчивается. Вместо этого можно было бы подставить любое выражение:


    public function someMethod($value = $this->defaultValue): void
    
    public $statuses = SomeClass::getStatuses();

    Мне было бы очень удобно.


    7. Указание типа переменным


    Тут много написать не получится, так как (1) и так все понятно, (2) и так всем известно. Хочу сказать только то, что из PHP не обязательно делать язык со строгой типизацией. Достаточно только дать такую возможность. А дальше пусть каждый решает сам, как ему пользоваться этим. Но для тех, кто пришел с языков со строгой типизацией, PHP станет более привлекательным.


    8. Убрать function


    Не совсем понимаю необходимость ключевого слова function в указании методов класса.


    public function someMethod()
    // Или
    public someMethod()

    Это чисто субъективный момент. Но в тех языках, которые я знаю помимо PHP, а именно Java и JavaScript, я этого не наблюдаю. Действительно, а зачем? Семантически это слово никакой роли не играет. Я и без того пойму, где функция, а где свойство. Но кажется, что убрав лишние 9 символов, будет немного больше места для аргументов и меньше визуального шума. А это небольшой, но плюс.


    9. Навести порядок


    Беспорядок, пожалуй, самый весомый аргумент против языка. Сложно отрицать, что в PHP много странных непоследовательных решений, в отношении названия функций, порядка аргументов и п.р. Всё понимаю: обратная совместимость, "исторически сложилось", влияние других языков. Но нужно двигаться дальше!
    Как вариант, можно большинство функций перенести внутрь объектов, как я описал в самом первом пункте, остальные реализовать в качестве статических методов этих классов (например Array::method()), а все остальное пометить как deprecated. А в следующей версии повыкидывать все!


    Как по мне, PHP неплохо развивается как ОО язык, и большинство функций, констант и п.р. можно переместить в классы (json_encode -> Json::encode, cUrl).
    Если бы кто-нибудь сделал расширение, которое решает эти проблемы, переносит все функции в статичные методы классов, написал полифил, если вдруг расширение не установлено, и для Codesniffer написал варнинги при использовании старых функций… Я бы уже сейчас стал использовать его. Мне кажется, что не только я. Вопрос только в том, что это должно быть именно расширение, которое максимально эффективно прокидывает аргументы из метода в нативную функцию.


    Вместо заключения


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


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


    Еще что хочу сказать. Это все субъективно. Это то, что хочу конкретно я. К тому же, на мое мнение повлияло изучение Java. И мне понравились некоторые возможности этого языка. Но это вовсе не говорит о том, что так надо или что это единственно верное решение.


    А что Вы хотели бы увидеть или изменить в PHP?

    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 241
      +2
        +7

        Было бы все просто, если было бы все просто. RFC писать без предварительной реализации и без тестов не имеет особого смысла (там так и сказано). Я бы с удовольствием поддержал проект кодом. Но сколько времени займет изучение языка C и исследование внутренностей проекта, прежде чем я смогу написать что-то толковое? С учетом полной рабочей занятости, на это могут уйти годы...

          +10

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


          Но давайте вспомним почему в php нет вещей в статье:


          1. синтаксис с "точкой" (точнее с -> для операций над скалярами) — нет и не будет потому что заведомо проигрышная штука. Она в разы проигрывает тому же pipe оператору в плане гибкости и сложности реализации. А то что люди "привыкли" — это вопрос к тому что нужно правильно людям подать идею что бы они забросили мертвые концепты. PHP на js, там нет прототипного наследования, манкипатчинг в php никто не хочет (и правильно делает), так что нечего.

          вот pipe оператор дело другое:


          $result = [1, 2, 3, 4]
             |> usort(($a, $b) => $a->foo <=> $b->foo)

          1. дженерики: сложна, существует RFC и даже существуют люди которые чето пилят и обещают нам дженерики в 8-ой версии. Но есть нюансы с описанием поведения дженериков (RFC не доконца проработана и уже слишком большая) + есть целая гильдия противников подобных вещей в php. Ну и главная проблема — то что php единственный язык из тех что я знаю который делает подобные проверки в рантайме. Это глупо и в целом только по этой причине реализация тех же дженериков усложняется на порядки (потому например мы не имеем тайпхинтинга для пропертей — была реализация но сделать без сущенственного оверхэда на рантайм не вышло).


          2. Аннотации (а точнее это больше походит на атрибуты) — основная причина по которой несколько RFC загнулись — либо расхождение во взглядах (кто-то хочет декораторы а кому-то достаточно атрибутов), расхождения в поведении (влияние на рантайм), ну и просто очень плохо проработанная RFC и плохая подача в комьюнити. Ну и так все заглохло.


          3. короткие функции напоролись на ограничения парсера. Символ => уже занят в выражениях, как и ->, варианты из Hack (==>) никому не понравились, варианты fn($x) => $x **2 не нравятся потому что новый кейворд + нарушение обратной совместимости (кто-то уже может юзать функцию fn). Ну и последние варианты опять же уперлись во вкусовщину.


          4. Асинхронность. Вот тут в статье написан полный бред и чушь. Начиная с того что pthread тут не причем, и заканчивая тем что async/await и event loop на уровне ядра было бы круто, но не обязательно.

          Было обсуждение ввести в php stackless корутины но вы можете юзать их и так через экстеншен. Да и решений для асинхронности полно.


          С другой стороны среднестатистический php разработчик понятия не имеет как работает сборщик мусора и в целом весьма сильно полагается на модель "а оно потом умрет и все будет ок" что плохо совместимо со всей этой культурой. Все это делает фичи в духе асинхронности мало востребованными, ибо те кто хотят и так могут. Просто не так красиво и удобно.


          1. Невозможно. Просто в силу того как реализован php. Ну то есть не то что бы невозможно, но сложно. Да и не очень то и нужно.


          2. Тайпинг для переменных и пропертей — была даже реализация но как я писал выше — из-за любви к проверке типов в рантайме никто ради этой фичи не стал жертвовать 30% оверхэдом по рантайму.


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


          4. Меня всегда бесило это нытье. Никто и никогда не мешал никому сделать пакет на packagist с элиасами для функций раскиданными по нэймеспейсам. И вместо того что бы решить проблему люди просто продолжают ныть.

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


          Есть проекты вроде preprocess.io которые решают все озвученные проблемы (либо минимизируют эффект), есть анализаторы вроде psalm, есть куча крутых решений проблем, есть language server в конце концов и возможность писать свои DSL и синтаксисы с транспайлом в php и совместимостью. Но нет, всем надо просто и из коробки.

        +1
        explode, нет?
          0

          Спасибо, исправил

          +8

          По поводу асинхронности — давно делают файберы, но пока в ядро протащить не получается (https://wiki.php.net/rfc/fiber, https://externals.io/message/101808).
          А сторонних реализаций eventloop хватает.
          Да и вообще, почти по всем пунктам, уже были или попытки что-то сделать по указанным направлениям, но протащить дальше rfc не удавалось.

              +2
              There are currently no reports of these vulnerabilities being exploited in the wild.

              Ну и вообще говоря прикольно видеть ченджлог в качестве отчета об уязвимости:))

              –15
              PHP может стать еще лучше
              А может не стать.
                +6
                Указание типа переменным
                … не обязательно делать язык со строгой типизацией

                снова кто-то путает строгую (сильную) и статическую типизацию

                  +1
                  Пункт номер 1 — это было бы прекрасно. После JS очень коробит делать что-то вроде
                  $something = explode($list, ",");
                  
                  $result = [];
                  foreach($something as $item){
                       $result[] = doAction($item);
                  }
                  
                  Вместо
                  $something = $list->explode(",")
                                    ->map($item => doAction($item));
                    +1
                    Гляньте на эти коллекции
                    Для большинства случаев они очень неплохи.
                      +1
                      Лучше ларовские: laravel.com/docs/5.6/collections У них плюшек на несколько порядок больше, включая High Order Messaging и прочую дичь)
                        +1

                        Если уже используется laravel или lumen, то ага. А так целый illuminate/support тащить, да еще с этими фасадами — ну как то не знаю.

                            0
                            nayjest/collection
                            composer require nayjest/collection
                              0
                              И всё же оригинал лучше, имхо. Это раньше он половину ядря тянул за собой, сейчас же только контракты (набор из дестяка интерфейсов), что не является фатальным.

                              Зато получаем поддержку километрового сообщества, актуальность и набор хелперов, которые будут использоваться 146% если знать об их существовании (например, array_first/last или class_basename).

                              Я согласен, что там есть и лишнее (вроде базового класса фасадов или провайдеров), но эти пяток классов — не помешают, учитывая то, что вендор любого современного фрейма и так содержит тучу неиспользуемого кода. Нет, это не призыв тянуть за собой мусор, просто меньшее зло, выбирая которое профита можно получить на несколько порядков больше.
                                +3
                                > которые будут использоваться 146% если знать об их существовании

                                Знаю, но не использую, чтобы не создавать привязку к фреймворку.
                                  0
                                  А каким образом хелперы привязаны к фреймворку? Это примерно как утверждать, что не пользуюсь «sort», а пишу свою сортировку, т.к. «не хочу привязываться к stdlib php». Тот же class_basename выглядит как:
                                  function class_basename($class): string
                                      {
                                          $class = is_object($class) ? get_class($class) : $class;
                                  
                                          return basename(str_replace('\\', '/', $class));
                                      }
                                  


                                  Или я чего-то не понимаю?
                                    0
                                    В текущем проекте эта функция подключается с пути /vendor/laravel/framework/src/Illuminate/Support/helpers.php из состава пакета laravel/framework. Было бы выделено в отдельный пакет, не конфликтующий с этим, да в отдельном неймпейсе — использовал бы скорее всего.
                                      0
                                      Нет, из состава пакета illuminate/support: packagist.org/packages/illuminate/support

                                      Зачем весь фрейм тянуть-то?

                                      P.S.: github.com/laravel/framework/blob/5.6/composer.json#L67
                                        0
                                        Что вижу в коде, то и говорю. Нет в зависимостях illuminate/support, есть laravel/framework. Не ради этих хелперов, скорее всего, был добавлен фрейм, но увеличивать связанность с ним своими руками не хочется.

                                        Странное, как по мне, решение формально выделить в отдельный компонент часть фреймворка, но не документировать это: laravel.com/docs/5.6/helpers#introduction — где тут о возможности подключить отдельно, без подключения фреймворка? Сравните с аналогичным решением в symfony/symfony — переходишь на страницу документации компонента и первым делом видишь `composer require symfony/`. Возможно, исключительно из-за такого подхода к документированию у Laravel есть образ сильносвязанного фреймворка, где всё друг к другу гвоздями прибито.

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

                                        PS Посмотрел, нет, Eloquent не отдельный компонент, судя по всему, не выделен из illuminate/database. Хотя с новым знаниями глядя на документацию можно было бы так подумать. В документации вообще логика есть? :) Можно разобрать по ней, где отдельный компонент, который можно затянуть в любой проект, а где нужно будет вручную выпиливать?

                                        PPS В любом случае у меня культурный шок, что laravel оказывается не монолит и некоторые из фактических зависимостей от laravel/framework можно одной строчкой в composer.json выделить. Спасибо.
                                          0
                                          Посмотрел, нет, Eloquent не отдельный компонент, судя по всему, не выделен из illuminate/database.


                                          illuminate/database и есть этот самый Eloquent и миграции.
                                            0
                                            .А для миграций у нас phinx есть, например.
                                            0
                                            laravel оказывается не монолит

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

                      +6

                      Что-то типа такого?


                      $result = array_map(function($x) { return $x*$x;}, explode(',', '1,2,3'));

                      Array
                      (
                          [0] => 1
                          [1] => 4
                          [2] => 9
                      )
                      0
                      Раз такое обсуждение пошло, то внесу и я свои пожелания.

                      Конструкторы и di
                      После работы с magento 2 стало очевидно что нужно что-то делать с конструкторами когда внедряется di. Пример класса. Возможно, использование выражений на месте, как сказано в статье, спасет ситуацию.

                      Наследование классов
                      Знаю что проблема не php, а многих языков. Так и не пришел к хорошему решению проблемы с наследниками.
                      1 случай: имеется класс для выборки данных который нужно закэшировать. Можно сделать наследование и заменить все методы на кэширующие. Если класс под интерфейсом, то реализацию интерфейса. В обоих случаях придется дублировать все методы. Как это решить — не понятно.
                      2 случай: в magento 2 есть возможность переопределять классы (preference), но переопределить класс от которого кто-то наследуются напрямую (extends /Class) — нельзя. А класс еще может быть абстрактным. В итоге получаем кучу наследников которые нужно переопределять чтобы добавить общий метод. И простого решения нет. Трейт лишь облегчит ситуацию.
                        +6
                        Пример класса. Возможно, использование выражений на месте, как сказано в статье, спасет ситуацию.

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

                          0
                          Magento — суровый enterprise, еще и щедро приправленный legacy
                            +1
                            После работы с magento 2 стало очевидно что нужно что-то делать с конструкторами когда внедряется di. Пример класса.

                            С этой проблемой прекрасно справляются код-ревью и найм более квалифицированных специалистов.
                            0
                            Тут аннотации не то что не помогут, а заставят повторить простыню param просто с другим тегом типа inject. Тут разруха не в клозетах.
                              0
                              Слегка не по теме, но на 2 случай в мадженте есть плагины
                                0
                                Как и все в мадженте, они как бы есть, но использовать можно только где-то в 20% случаях.
                                Добавить метод через плагин? Нельзя.
                                Сделать замену метода где используются приватные методы? Можно, но бессмысленно (нельзя).

                                Плагины не отменяют проблему с наследниками. Точно так же нужно работать с каждым по-отдельности.
                                0

                                Мне вот недавно пришлось с головой окунуться в старый индокод, с десятками global в начале функций. В этом вашем примере класса из Magento вижу по сути то же самое, только приправленное ООП.


                                Не-не, как раз хорошо, что инъекции через конструктор. Были бы property injections по типу @Autowired — было бы не так заметно, какой там ад.

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

                                  В этом и заключается беда многих фремворков/цмс не использующих DI, что реальные зависимости классов скрыты
                                    0

                                    Вы так уверены, что можете поменять вот такую зависимость? :-)


                                    Не, SOLID работает, только когда все буковки сразу.

                                      0
                                      Я думаю что да. Просто это может потребовать кучи времени.
                                        0

                                        За кучу времени я и global-ы индусские переписать могу, вообще с нуля :-)

                                          0
                                          Мне кажется что если бы разработчики применили полноценное ddd то m2 если бы и вышла, то к концу десятилетия. Это если не смотреть сколько лет ушло на фиксы багов с 2.0…

                                          А еще при работе с системой проходят проверку на прочность все компоненты: php, mysql, phpstorm, composer. Я вот не уверен что разработчики composer планировали что обычный проект будет грузить сотни мегабайт кода. Или в jetbrains разрабатывали phpstorm только для тех у кого ssd… Куда еще увеличивать кодовую базу.
                                            0

                                            Да я это все прекрасно понимаю, у самого тонна криво спроектированного легаси, с которым приходится жить. Я это все к изначальному тезису про "надо что-то делать с конструкторами". Не надо. :-)

                                              0
                                              На надо во времена 5.6-7.0, уверен что на 7.5 вообще все перейдут на di и в каждом проекте будет вот это вот объявление параметра, занесение в конструктор, назначение в конструкторе, генерация docblock. В наследнике хочешь написать что-то в construct? Будь добр, тащи все зависимости в предок.

                                              Запрещать подход я не предлагаю. Я за расширение: в простых случаях по-старинке, а с десятком зависимостей по-другому.
                                                0

                                                А, в этом смысле. Тут можно позаимствовать сахарок из того же Typescript:


                                                constructor(private foo: FooInterface, private bar: BarInterface) {}

                                                Хотя в нормальной IDE с генерацией приватных свойств и присваиванием в конструкторе проблем нет, все делается автоматически.


                                                Docblock, который не добавляет никакой информации, а просто дублирует сигнатуру — нафиг не нужен. Если требуется правилами оформления — IDE сгенерирует сама.


                                                В наследнике хочешь написать что-то в construct?

                                                Ну, это вообще не очень нормально. Composition over inheritance, Abstract or final.

                                  0

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

                                  +2
                                  Согласен со многими пунктами. Сам собираю список того, чтобы я изменил в PHP — с кучей новых возможностей, разделением и оптимизацией стандартной библиотеки, упрощением синтаксиса, с цепочками функций стандартных функций, без оглядки на историческое наследие.
                                  Но это получается уже новый ЯП, несовместимый с PHP, но конвертируемый в/из него.
                                  Может, как-нибудь оформлю свои заметки в статью
                                    +1
                                    Отключение возможности неявного преобразования типов. Или, хотя бы, deprecated сообщения о его использовании.
                                      +3

                                      А что вам мешает сделать объектные обёртки для примитивов, как в JavaScript?
                                      ArrayObject уже давно есть.

                                        0
                                        Дорого и ужасно выглядит что-то вроде (new String("1,2,3"))->explode(",")->map(function (string $item) { return (new String($item))->intval();});
                                          +1

                                          Зато ж красота!


                                          И без new, есть же __invoke(). И это же php, intval не нужен, ну или в explode вторым параметром EXPLODE_CASTING_TYPE_INTEGER — придерживайтесь стиля phр ;-)

                                        –4

                                        Скоро линии развития PHP и Java сойдутся в одной точке пространства-времени. Но покуда жизненный цикл PHP скрипта будет 'выполнил задачу или запрос и сдох' по-насоящему лучше он не станет.

                                          +7
                                          Для своих целей PHP is good enough.
                                          А те вещи, которые действительно дорого поднимать можно запустить в виде демона, или вообще написать на другом, более подходящем языке.
                                            –1

                                            Границ у этих, так сказать, целей нет. В этом весь фокус. Достигнув простой цели, планка требований поднимется выше, потом ещё выше, и ещё… а потом бах и OutOfMemoryException, например.
                                            Так или иначе язык ограничен (любой язык), а задачи — нет. Так может разработчикам PHP пора начать делать что-то более серьезное чем добавление сахара из других языков? Начать с таймера и многопоточности, вот тогда язык станет языком вне конкуренции, а не темой для холиваров.

                                              +2
                                              За несколько последних лет с миграцией с 5.5 до 7.2 получил нереальное ускорение. Это что, не прогресс?
                                            +5

                                            В этом и есть его крутость.
                                            Вот представь, поднять на той же Java на одном сервере 100 сайтов, или 1000, или ещё больше. В PHP если на каждой из них нет большой нагрузки все ограничено дисковыми пространством, а Java будет стартовать каждый и держать все программу в памяти.


                                            Есть две Java (ещё C#), есть два Python (второй Ruby), а PHP реально имеет свою нишу, в которой он незаменим.


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


                                            В общем, нужно понимать инструмент и использовать тот, который нужен. Другое дело, что многие используют его там, где место Java и создают сете проблемы.

                                              0
                                              В PHP если на каждой из них нет большой нагрузки все ограничено дисковыми пространством
                                              Это Вы про тот случай, когда основными источниками трафика на сайте являются фрилансеры и их заказчики? Так для таких целей PHP хорош как он есть, и без всяких улучшений!
                                                0

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


                                                Большинство веба — это по сути CRUD, узелок место — это походы в бд, а те жалкие проценты, которые мог бы ускорить компилируемый язык, редко когда нужны (ну и есть модули на Си, и вершина развития этой идеи — Phalcon).


                                                А вот из скриптовых языков PHP на голову выше всех конкурентов, кроме Groovy(но там JVM и все прелести выяснения отношений с каким-то Tomcat). А Python и Ruby рядом не стоят.

                                            0
                                            Неявное временное преобразование примитива в объект

                                            Вы же понимаете, что это будет совершенно другой тогда ЯП? Смущает даже более формулировка "неявное временное", в Python и Ruby, скриптовых языках, к коим относится и PHP, всё представляет из себя объекты, смысл делать из PHP очередной Ruby, это противоречит его концепции? Безусловно, профит есть, но это уже полностью изменить язык, даже если учесть что это "временно"...


                                            1. Короткий синтаксис функций

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


                                            1. Убрать function

                                            Вот снова отсылка к JavaScript. Однако довольно странно это выглядит, в тех же упомянутых скриптовых языках, есть ключевое слово def для объявления функции, в PHP — это function. А вообще не стоит забывать, что PHP — мультипарадигмальный язык, где кроме поддержки ООП, есть и функциональная парадигма, в отличие от Java, а в JS — классы, как известно, синтаксический сахар, так что поэтому и нет лишнего ключевого слово. В общем, плохой, я бы даже назвал, рекомендацию убирать это, смотрится не очень, даже если учитывать, что это будет опциональная фишка, с целью не писать дополнительно 8 букв, находясь внутри контекста объекта...


                                            1. Навести порядок

                                            Многое сказано правильно, но json_encode -> Json::encode, вообще жутко, да и представить себе сложно уже, т.к. кажется, что это пользовательский класс Json со статическим методом encode, а не что-то родное от языка. Да и опять же, статические вызовы в данном случае смотрятся ужасно.


                                            Дженерики, декораторы асинхронность — лайк, и это реально можно, если уж не реализовать (хотя всё можно, конечно), то представить себе в контексте такого языка, как PHP, однозначно.

                                              +2
                                              На мой взгляд, json_encode -> Json::encode — очень хорошая замена, т.к. в стандартных библиотеках, коей является библиотека json, все функции, свойства константы идут с префиксом от наименования библиотеки, что иногда затрудняет чтение кода (не в случае json, конечно).
                                              Зато все константы JSON_*, которые идут в этой библиотеке, можно будет вызывать не из глобального пространства, а как константы класса JSON
                                              Вообще, как многие справедливо ругают, в PHP слишком много функций находится в глобальном пространстве. Кроме этого, данная замена позволит гибко управлять и переопределять эти функции.
                                                +1
                                                Я имел в виду, что более привычно видеть обычные функции, нежели чем статические вызовы классов, если используешь встроенные возможности PHP. Возможно, я слишком привык к этому, но большое изменение, и меня смущает именно эти статические вызовы, опять-таки, скорее всего моя проблема.
                                                  0
                                                  Нет, это не ваша проблема.
                                                  В PHP функции стандартной библиотеки являются интринсиками (не уверен в корректности термина применительно к PHP, но по смыслу ближе всего) и работают с примитивными типами:

                                                  _zend_value{
                                                      zend_long         lval;  //int64_t
                                                      double            dval;
                                                      zend_string      *str;  //uchar
                                                  ...
                                                  }


                                                  В случае объекта — это дополнительные накладные расходы на создание и хранение этого самого объекта.
                                                    0
                                                    Т.к. это расширение, данный объект создаётся 1 раз при запуске php. Расходы на хранение не такие уж и большие.
                                                    Если сравнивать варианты выполнения функции:
                                                    1. json_encode: найти в локальном пространстве функцию json_encode, если в нём не найдём (что скорее всего и будет), ищем её в глобальном пространстве.
                                                    2. JSON::encode: найти класс JSON, затем в нём найти статический метод encode.

                                                    Мне кажется, что 2-ой способ будет выполняться быстрее. Могу ошибаться, не знаток внутренностей PHP.
                                                      0
                                                      На первый вариант можно использовать \json_encode, защитит от переопределений и скажет сразу искать в глобальном пространстве, хотя производительность не замерял.
                                                        0
                                                        1. Т.к. это расширение, то мы уже имеем увеличение вермени от получения запроса до начала его обработки, так как его надо загрузить и подготовить. Ну это я чисто придраться.
                                                        2. Для JSON::encode разрешение имен будет идти абсолютно по такому же пути — сперва будет происходить поиск класса JSON в локальном пространстве имен, а потом в глобальном.
                                                          0
                                                          1. Нет, загрузка расширения (и его классов) идёт всего 1 раз во время поднятия PHP (или инстансов php-fpm), а не на каждый запрос.
                                                          2. На мой взгляд, код \JSON::encode выглядит гораздо гармоничней, чем \json_encode. Но это чисто моё мнение.

                                                          Плюс, как я думаю, поиск в локальных/глобальных классах будет будет идти быстрее, чем в функциях, т.к. их намного меньше. Но точно этого не знаю, т.к. надо измерять.
                                                            0
                                                            1. Вот хорошая статья про жизненный цикл PHP
                                                            2. Да я, собственно, не против. PHP позиционируется как мультипарадигменный язык. Кому-то нравится ООП, кому-то процедурный стиль.

                                                            Вы вполне можете сделать свой утилитный класс с красивыми методами, проксирующими к некрасивым стандартным функциям (лично я так иногда и делаю) и даже вынести его в расширение — это не так сложно делается.

                                                      0
                                                      А чем в глобальном плане различаются «встроенные возможности» от сторонних библиотек? В самих встроенных библиотеках вообще можно найти разброд и ахтунг.
                                                      Например, встроенное расширение intl. Если зайти на страницу документации php.net/manual/ru/book.intl.php и почитать названия методов, то волосы встают дыбом — смесь CamelCase, слитное написание наименований без заглавных букв, «стандартное» наименование функций прописными буквами, разделённые нижним подчёркиванием. Плюс дублирование многих функций в процедурном стиле (функции вызываются из загруженного глобального пространства) и ООП.
                                                      В то время, как сторонние библиотеки (далеко не все, конечно) стараются держаться ООП либо вызова статических методов.
                                                        0
                                                        А чем в глобальном плане различаются «встроенные возможности» от сторонних библиотек?

                                                        Из этой фразы стоит убрать слово "сторонних".
                                                        В PHP есть стандартная библиотека, содержащаяся вот прямо внутри исходного кода PHP, куда входит не такое уж и большое количество функций.
                                                        Все остальное подключается с помощью библиотек расширений — это то, что лежит в каталоге ext и включается в php.ini


                                                        (библиотеки PECL отличается от "стандартных библиотек" только тем, что они не доступны "из коробки" и подключать/компилировать их нужно самостоятельно)


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

                                                          0
                                                          Под «глобальным» я имею только их выполнение, а не способ подключения.
                                                          JSON — та же библиотека, только «вшитая» в ядро. Я не про неё конкретно. Есть достаточно много таких «вшитых» библиотек, некоторые из которых можно отключить при компиляции.
                                                          Так что в глобальном плане они не отличаются от сторонних. Только образование наименований функций отличается. И это порой создаёт путаницу.
                                                          Понимаю, что это из-за наследия формирования PHP, и что это не изменить. Но такая разнородность «не красит» язык.
                                                          Всё написанное прошу считать моими «мысли вслух». Это просто тезисы моего ЯП, который я создаю на основе PHP, существующий только в моей голове.
                                                            +1

                                                            Видимо я не совсем понятно объяснил.
                                                            В PHP нет "вшитых" библиотек кроме standard, которую нельзя отключить. И, в частности, практически все функции работы с однобайтовыми строками содержатся именно в ней.


                                                            Все, что можно отключить/подключить — является библиотеками, которые довольно условно делятся на два типа — те, которые включены в поставку (например mbstring или json) и те, которые PECL.

                                                  0
                                                  Многое из перечисленного уже есть на wiki.php.net/rfc в качестве предложений.
                                                  Про многопоточность в каждом еженедельном дайджесте про PHP на хабре есть отсылки.
                                                  если убрать слово `function`, то, насколько я понимаю, сильно усложнится процесс токенизации, что печально скажется на производительности. Да и не факт, что без жестко поломанной обратной совместимости не обойдется, если вдруг.
                                                    0
                                                    Вы не против если я выскажу мысли с другой стороны баррикад. Нам это не нужно, это нужно Вам. Нужно для переписывания кода и получения очередного вознаграждения когда выйдет очередной PHP X, а поддержка старых версий на хостингах сойдёт на нет.
                                                      0
                                                      «другая сторона» — это индийский аутсорс, что ли? Или эффективный менеджмент?
                                                      0

                                                      Да, сахарка со стрелочными функциями очень хотелось бы, а если это еще приправить штукой типа https://github.com/sebastiaanluca/php-pipe-operator c поддержкой из коробки, будет совсем замечательно
                                                      Ну и про порядок с array_map/array_filter etc. и со строковыми функциями конечно тоже наболело, понятно что оберток хватает, но и нативных подвижек хотелось бы

                                                        0

                                                        И еще, если не дженерики, то хотябы в phpdoc описание структуры массива


                                                        array[<string>, <int>], array[<int>, SomeClass[]]
                                                          0
                                                          Ну и про порядок с array_map/array_filter etc. и со строковыми функциями конечно тоже наболело

                                                          Малейший чих в сторону изменения поведения/порядка аргументов в функциях стандартной библиотеки PHP равносилен развязыванию маленькой ядерной войны — вроде и маленькая, но трясти и корёжить будет весь мир. Ситуация, конечно, очень печальная и, как мне кажется, решением может быть только создание параллельной стандартной библиотеки с постепенной (через 3-4 мажорных релиза) деприкацией старой.
                                                            +1

                                                            Можно было упрятать все эти старые стандартные функции в какой-нибудь namespace и пометить как deprecated и сделать им модные современные алиасы с однотипным наименованием функции и порядком аргументов.
                                                            Кто хочет пользоваться старыми для поддержки legacy, тот подключает namespace legaсу, а остальные переходят постепенно на новые, причём этот переход можно было бы почти полностью автоматизировать средствами самого языка.
                                                            Я думал, что так и сделают с введением namespace.

                                                              0
                                                              В предлагаемом вами решении есть очень много спорного, но все это меркнет на фоне того, что оно ломает обратную совместимость практически со всем написанным на PHP коде, за все время существования языка.
                                                                0

                                                                Как раз не ломает же. Старые функции помечаются как deprecated, но работают.

                                                                  0
                                                                  PHP сперва ищет функцию в локальном пространстве имен, после чего, если не найдет, ищет в корневом (\).
                                                                  Теперь представим, что старую стандартную библиотеку вынесли в отдельное пространство имен и добавили третий шаг в алгоритм разрешения (что само по себе костыль в ядро языка).
                                                                  Тут же в проекте появится падаван, который лихо объявляет во входной точке API, в рутовом пространстве имен, что-то вроде
                                                                  function strstr($a){
                                                                      echo $a;
                                                                  }

                                                                  И всё заверте…

                                                                  Пример конечно утрированный, но нарушение обратной совместимости демонстрирует.
                                                                    0

                                                                    Это будет уже новый код, от выстрелов в ногу везде защиту не поставишь.
                                                                    И да, такое поведение иногда даже желательно, можно делать так:
                                                                    `function strstr($a){
                                                                    log();
                                                                    return legacy\strstr($a);
                                                                    }

                                                                0

                                                                Так не сделают. На php куча кода, который поддерживать вообще некому, просто работает и работает.


                                                                Имеет смысл добавить ООП-варианты вида $array->map(...)->reduce(...) / $string->length(), а функции оставить как были для обратной совместимости.

                                                                  0
                                                                  На php куча кода, который поддерживать вообще некому, просто работает и работает.

                                                                  Тогда там и версию PHP некому будет обновить, а значит ничего не сломается:)

                                                                    0

                                                                    А оно с обновлениями серверов ломается. Какой-нибудь Pentium 4 с Debian Etch не вечен. :-)


                                                                    Мне вот до сих пор для старого кода приходится держать PHP 5.3, например, и только потому, что придумали сломать call_by_ref в идиотской манере. Причем, если таки сделают explicit_send_by_ref, — а это именно то, как call by ref
                                                                    в этом старом коде используется — можно будет сразу ставить 7.3 (или что там будет) — все должно завестись (разве что для совсем-совсем старого кода времен php4 понадобится полифилл на ext/mysql).

                                                              +1
                                                              array_map/array_filter

                                                              Тут порядок легко запомнить:


                                                              • у array_map varargs, чтобы скормить несколько массивов,
                                                              • array_filter можно использовать без второго аргумента, что идентично function($v) { return !!$v; }.

                                                              Вот со строковыми функциями сложнее, впрочем, IDE всегда подскажет :-)

                                                              –9
                                                              image

                                                              А магнитные полюса земли в ближайшее время…
                                                              Как бы это вам сказать…
                                                              Магнитные полюса… знаете ли…

                                                              Не изменятся.
                                                                0
                                                                в ближайшее время

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

                                                                0

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


                                                                А ведь, казалось бы, очевидные кандидаты на улучшение.

                                                                  0

                                                                  Конечно, меня это тоже бесит, но на счёт $ под точно проблема вылезет в том, что в строке "..." не понятно как искать переменную. Это то, что на поверхности, может ещё какие-то трудности.


                                                                  А по -> — это переписать весь существующий код на PHP, и это не Java, где что-то скомпилировать можно и старым компилятором, тут вообще все умножится на ноль. В Плюсах с этим как-то живут.

                                                                    0
                                                                    В других языках как-то без $ обходятся. И в плюсах между. и -> есть разница.
                                                                      +1

                                                                      Вообще-то я не говорил, что без этого нельзя сделать язык, я говорил, что это сломает слишком много кода.


                                                                      На счёт точки в Плюсах, там она не используется для конкатенации строк.

                                                                        0
                                                                        Допустим отказались от знака доллара. Как токенизатору толковать вот такую строку?
                                                                        a();

                                                                        Вызов функции `a`?
                                                                        Вызов метода `__invoke()` у класса, хранящегося в переменной `a`?
                                                                        Вызов функции, имя которой хранится в переменной `a`?
                                                                        Еще как-то?
                                                                          0
                                                                          Вызов функции a?
                                                                          Вызов метода __invoke() у класса, хранящегося в переменной a?

                                                                          Вызывать то, что ближе по области видимости. Если функция a есть в области видимости и переменная есть в области видимости — отдавать предочтение переменной или придумать другое однозначно трактуемое правило.


                                                                          Вызов функции, имя которой хранится в переменной a?

                                                                          Если хочется вызвать функцию, имя которой хранится в переменной a, можно оставить возможность поставить перед переменной a знак доллара.

                                                                            +3
                                                                            или придумать другое однозначно трактуемое правило.

                                                                            Например однозначное определение переменной с использованием символа $


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

                                                                              –1
                                                                              или придумать другое однозначно трактуемое правило.
                                                                              Например однозначное определение переменной с использованием символа $

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


                                                                              Описываемое вами поведение, когда у a() может означать вызов функции, а может означать вызов метода у объекта, который хранится в переменной a, присутствует в C++ и, если программистам на C++ предложить ради упрощения разруливания этого кейса ставить значок доллара перед каждой переменной, они просто покрутят пальцем у виска.


                                                                              Особенно странно заниматься этим из-за оскорбленного эстетического чувства довольно малой части разработчиков.

                                                                              Эстетика тут не при чём. Набирать $ перед каждой переменной объективно неудобно и в этом объективно нет необходимости.

                                                                                +1
                                                                                если программистам на C++ предложить

                                                                                Зачем вы пытаетесь сравнивать ежа и ужа?


                                                                                Сходите к перловикам и расскажите, что ажно три разных префикса для переменных — это неудобно.
                                                                                Сходите к дельфистам и расскажите, что := — это трешь.
                                                                                Сходите к сишникам и объявите, что от вездесущих * и & в глазах рябит.
                                                                                Поведайте питонщикам, что выделять блоки кода отступами — это за гранью добра и зла.
                                                                                Расскажите создателям Kotlin, что типы должны быть слева, потому что вы в Java так привыкли.
                                                                                они просто покрутят пальцем у виска.©


                                                                                Синтаксис любого языка вырабатывается с конкретными целями. У использования доллара как префикса переменной в PHP есть конкретная цель — однозначное определение переменной в коде. А нужно это для:


                                                                                1. Облегчения чтения кода. Вы ведь помните, что 80% времени разработчик именно читает код?
                                                                                2. Ускорение работы парсера. Для PHP по сути его критично время старта.
                                                                                  –1
                                                                                  Зачем вы пытаетесь сравнивать ежа и ужа?

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


                                                                                  Теперь по пунктам про приведённые вами утверждения


                                                                                  Сходите к перловикам и расскажите, что ажно три разных префикса для переменных — это неудобно.

                                                                                  Неудобно, но в перле эти префиксы хотя бы нужны для раделения типов переменных.


                                                                                  Сходите к дельфистам и расскажите, что := — это треш.

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


                                                                                  Сходите к сишникам и объявите, что от вездесущих * и & в глазах рябит.

                                                                                  Вот тут вы собственноручно приступили к сравнению ежа с ужом. У символов * и & в Си есть смысл, убрать их просто так невозможно.


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

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


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

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

                                                                                    0
                                                                                    [промахнулся]
                                                                                    0
                                                                                    Синтаксис любого языка вырабатывается с конкретными целями.

                                                                                    И конкретной целью необходимости ставить знак доллара перед переменной в PHP было обеспечить возможность вставлять переменные в строки.


                                                                                    Облегчения чтения кода. Вы ведь помните, что 80% времени разработчик именно читает код?

                                                                                    В IDE можно подкрасить переменную любым интересным вам цветом. Также IDE подкрашивает переменные в зависимости от дополнительных факторов. Знак доллара облегчает чтение кода только если вы используете какой-то текстовый редактор типа Блокнот.


                                                                                    Ускорение работы парсера. Для PHP по сути его критично время старта.

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

                                                                                      +1
                                                                                      И конкретной целью необходимости ставить знак доллара перед переменной в PHP было обеспечить возможность вставлять переменные в строки.
                                                                                      Позвольте не поверить и попросить предоставить пруфы.

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

                                                                                      Ну это даже не смешно. Во-первых, существенно на время старта наличие или отсутсвие значка доллара не влияет, во-вторых те, кому это по настоящему критично — компилируют код заранее.
                                                                                      Во-первых — повлияет.
                                                                                      Во-вторых — это как раз критично для всех, кроме high load (для них тоже критично, но только на прогреве). А таковых подавляющее большинство. Тут на хабре были статьи про критичность времени отклика — почитайте.

                                                                                      Я в ответ пишу, что в языке программирования, в котором фича с долларом отсутствует — никто не спешит её добавлять.
                                                                                      А в языках, где присутствует — никто не спешит убирать. Вам не кажется, что это прямо про притчу о своем уставе в чужом монастыре?

                                                                                      Почему-то вместо этой, по вашему мнению разумной альтернативы, комитет по развитию С++ предпочитает ввести правило.
                                                                                      А мантейнеры PHP, почему-то, предпочитают оставить доллар. При этом они не лезут в комитет по развитию С++ с предложением все переделать как у них. Странно, правда?
                                                                                        0
                                                                                        Позвольте не поверить и попросить предоставить пруфы.

                                                                                        Ну вот, например.


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

                                                                                        То есть доллар перед переменными нужен тем, кто пользуется этими редакторами? А что это за редакторы? Можно поимённо? Вы, кстати, пользуетесь ими? Или в IDE пишете?


                                                                                        Во-первых — повлияет.

                                                                                        И, конечно, у вас есть результаты тестов? Или какие-то другие пруфы? Есть?


                                                                                        Во-вторых — это как раз критично для всех

                                                                                        Значит все должны компилировать код заранее. Это ускорит старт сильнее, чем доллары перед именами переменных.


                                                                                        А в языках, где присутствует — никто не спешит убирать.

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


                                                                                        Вам не кажется, что это прямо про притчу о своем уставе в чужом монастыре?

                                                                                        Это не притча, это пословица :). И это пословица о том, что необходимо соблюдать установленные правила, а не о том, что их нельзя обсуждать.


                                                                                        А мантейнеры PHP, почему-то, предпочитают оставить доллар.

                                                                                        Так уж здесь заведено. О том, что можно по другому, почему-то мало кто задумывается.


                                                                                        При этом они не лезут в комитет по развитию С++ с предложением все переделать как у них. Странно, правда?

                                                                                        Да и члены комитета по развитию С++ не лезут к майнтейнерам PHP с предложением всё переделать как у них. Вас это тоже удивляет?

                                                                                          0
                                                                                          Ну вот, например.
                                                                                          Источник так себе, но да ладно. Вопрос на засыпку — какой процесс облегчается в результате «an ability to insert variables inside literal string values»? Не парсинг ли?

                                                                                          А что это за редакторы? Можно поимённо? Вы, кстати, пользуетесь ими? Или в IDE пишете?
                                                                                          Например vi и notepad++. Постоянно пользуюсь обоими, хотя имею опенсорсную лицензию на все продукты JetBrains. (нет, notepad++ НЕ обладает развитыми возможностями подсветки синтаксиса. vi тем более)

                                                                                          И, конечно, у вас есть результаты тестов?
                                                                                          А у вас? У меня есть опыт написания расширений к PHP, ковыряния в его коде и изучения принципов работы.

                                                                                          И в каких языках нужно перед каждой переменной ставить один и тот же символ?
                                                                                          Perl. Перед каждой переменной конкретного типа ставится фиксированный префикс. В PHP тип один — ```zend_value```

                                                                                          О том, что можно по другому, почему-то мало кто задумывается.
                                                                                          Не, ну кто бы спорил. Все вокруг дураки. Слава богу один умный нашелся и всем глаза раскрыл.

                                                                                          Да и члены комитета по развитию С++ не лезут к майнтейнерам PHP с предложением всё переделать как у них
                                                                                          Тем более странно, что лезете вы и потрясаете их комитетом.

                                                                                          Вишенка на торте.
                                                                                          Как я уже писал, надо компилировать заранее, а не затачивать синтаксис под нужды компилятора.
                                                                                          А что еще все должны делать?
                                                                                          Вам не кажется, что это несколько странное пожелание для интерпритируемого языка? (дабы избежать лишней итерации переписки — я пишу на Java, Kotlin, PHP, C, Objective C и чутка на ассемблере — для души)
                                                                                            0
                                                                                            Вопрос на засыпку — какой процесс облегчается в результате «an ability to insert variables inside literal string values»? Не парсинг ли?

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


                                                                                            (нет, notepad++ НЕ обладает развитыми возможностями подсветки синтаксиса. vi тем более)

                                                                                            Во-первых у vim возможности подсветки получше, чем у notepad++, а во-вторых подсветки и того и другого хватает, чтобы выделить всё, кроме собственно переменных. Для того, чтобы проблемы появились, надо использовать notepad.


                                                                                            У меня есть опыт написания расширений к PHP, ковыряния в его коде и изучения принципов работы.

                                                                                            А для доказательства вашего утверждения нужны результаты тестов, демонстрирующие, насколько отсутствие доллара замедляет разбор файла.


                                                                                            Perl. Перед каждой переменной конкретного типа ставится фиксированный префикс.

                                                                                            Этих префиксов несколько. Поэтому, что один и тот же символ нужно ставить перед каждой переменной, сказать нельзя.


                                                                                            Тем более странно, что лезете вы и потрясаете их комитетом.

                                                                                            Странно, что вас удивляет, что я написал, как можно улучшить PHP в статье про то, как можно улучшить PHP. Так же очень странно, что вы охарактеризовали мои слова как "потрясание комитетом", да и то, что вы вообще написали, что майнтейнеры не лезут с советами к комитету по развитию С++ очень странно. Создаётся впечатление, что вы воспринимаете выражение моей позиции как попытку покуситься на что-то сакральное.


                                                                                            А что еще все должны делать?

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


                                                                                            Вам не кажется, что это несколько странное пожелание для интерпритируемого языка?

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

                                                                                              0
                                                                                              Во-первых у vim… во-вторых подсветки и того и другого хватает...
                                                                                              Во-первых не vim, а vi.
                                                                                              Во-вторых — подсветки хватает, пока парсер редактора может однозначно определить переменную. Когда он этого сделать не может, то и подсветка начинает уже не помогать, а мешать. Даже у Idea бывает крышу сносит на, вроде бы, «правильных» языках, что уж говорить о других редакторах.

                                                                                              А для доказательства вашего утверждения
                                                                                              Начнем с того, что это именно вы утверждаете, что никак не скажется. Извините, но в случае парсера ЯП доказывать отсутствие импакта должен предлагающий изменения.

                                                                                              Поэтому, что один и тот же символ нужно ставить перед каждой переменной, сказать нельзя.
                                                                                              Перед каждым скаляром надо ставить $. Перед каждой хэш-таблицей надо ставить %. Перед каждым массивом надо ставить @.

                                                                                              Странно, что вас удивляет, что я написал, как можно улучшить PHP в статье про то, как можно улучшить PHP.
                                                                                              Меня удивляет, что в статье про то, как можно улучшит PHP, вы предлагаете переделать его в С++. Не более того. Спасибо — не надо. Когда мне нужен С++ — я пользуюсь им, но когда мне нужен PHP, то и беру я PHP.

                                                                                              Кажется, но вы же сказали, что тут особый случай, потому что скрипт запускается и компилируется заново при каждом запросе. Значит надо компилировать.
                                                                                              То, что мотоцикл имеет два колеса и может упасть на бок(пока не едет) не означает, что нужно приделать ему еще два и превратить его в машину.
                                                                                                0
                                                                                                Во-первых не vim, а vi.

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


                                                                                                Начнем с того, что это именно вы утверждаете, что никак не скажется.

                                                                                                Началось всё с вашего утверждения о том, что скажется, причём скажется существенно.


                                                                                                Перед каждым скаляром надо ставить $. Перед каждой хэш-таблицей надо ставить %. Перед каждым массивом надо ставить @.

                                                                                                Да, перед разными видами переменных надо ставить разные префиксы. Поэтому утверждение, что в Perl перед всеми переменными нужно ставить один и тот же символ — ложно.


                                                                                                Меня удивляет, что в статье про то, как можно улучшит PHP, вы предлагаете переделать его в С++.

                                                                                                Это неправда, я этого не предлагал.


                                                                                                То, что мотоцикл имеет два колеса и может упасть на бок(пока не едет) не означает, что нужно приделать ему еще два и превратить его в машину.

                                                                                                Поясните, пожалуйста, что вы хотели этим сказать.

                                                                                                  0
                                                                                                  что объясняет, например, ваше нежелание компилировать код
                                                                                                  :facepalm:
                                                                                                  Вы понимаете, что PHP — это скриптовый (интерпритируемый) язык? Что он потому и подходит для решения определенного скопа задач именно потому, что его не надо компилировать?

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

                                                                                                  Да, перед разными видами переменных надо ставить разные префиксы. Поэтому утверждение, что в Perl перед всеми переменными нужно ставить один и тот же символ — ложно.

                                                                                                  В PHP не перед всеми переменными и не всегда надо ставить символ $. Сталобыть ваше утверждение также ложно.

                                                                                                  Это неправда, я этого не предлагал.
                                                                                                  Именно к этому вы и ведете. Сначала вы предлагаете убрать $, аргументируя, что С++ обходятся без него. Потом начали рассказывать про компиляцию. Это все здорово, но непонятно, причем тут PHP?

                                                                                                  Поясните, пожалуйста, что вы хотели этим сказать.
                                                                                                  Ровно то, что сказал. То, что для PHP критична производительность парсера не значит, что его надо превращать в компилируемый язык.
                                                                                                    0
                                                                                                    Вы понимаете, что PHP — это скриптовый (интерпритируемый) язык?

                                                                                                    Понимаю.


                                                                                                    Что он потому и подходит для решения определенного скопа задач именно потому, что его не надо компилировать?

                                                                                                    Да, но с ваших слов веб к этим задачам не относится, потому что всем надо делать так, чтобы скрипт стартовал как можно скорее. Самый лучший способ это сделать — компилировать заранее.


                                                                                                    В PHP не перед всеми переменными и не всегда надо ставить символ $. Сталобыть ваше утверждение также ложно.

                                                                                                    То есть, если доллара нет, то нельзя точно сказать, что перед нами не переменная? И в каких случаях не нужно ставить доллар перед переменными?


                                                                                                    Именно к этому вы и ведете.

                                                                                                    Нет, не веду.


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

                                                                                                    Мой аргумент — необходимости в долларе нет и другие языки прекрасно это демонстрируют. Вместо С++ можно взять какой-нибудь другой пример.


                                                                                                    Потом начали рассказывать про компиляцию.

                                                                                                    С ваших слов надо уменьшать время старта скрипта. Вот я и заговорил про компиляцию.


                                                                                                    Это все здорово, но непонятно, причем тут PHP?

                                                                                                    Необходимость ставить знак доллара перед каждой переменной — объективный недостаток PHP, необходимость компилировать скрипты на PHP следует из ваших слов о необходимости ускорять старт. Вот причём тут PHP.


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

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

                                                                                                      0
                                                                                                      > Необходимость ставить знак доллара перед каждой переменной — объективный недостаток PHP

                                                                                                      Это так же его объективное преимущество, упрощающее и ускоряющее трансляци. Иными словами, объективно это компромисс между субъективными «лучше».
                                                                                                        0

                                                                                                        Для того, чтобы знако доллара был объективным преимуществом php потому что он ускоряет трансляцию, время трансляции должно быть очень критично и убирание знака доллара должно эту трансляцию существенно замедлять.


                                                                                                        С моей точки зрения, время трансляции не очень критично, потому что трансляцию можно делать заранее. Я уже несколько раз высказал это в комментариях и мне ответили, что не надо заранее компилировать интерпретируемый язык потому что это неправильно. Мне этот аргуент кажется недостаточным.


                                                                                                        Возможно у вас есть ещё аргументы против трансляции заранее?

                                                                                                          0
                                                                                                          Трансляция заранее превращает интерпретируемый язык в компилируемый, лишая его плюсов интерпретируемых или заставляя внутри стандартной библиотеки создавать интерпретатор для работы функций типа eval(), чтобы хотя бы части плюсов не лишиться. Вам нужны плюсы интерпретируемых?
                                                                                                            0

                                                                                                            В целом я не считаю проблемой если парсер php вдруг начнет в два раза дольше разбирать код, если мне будут доступны более удобные синтаксические конструкции. Да и разговоры о AOT компиляции php ходят уже пару лет как.


                                                                                                            Как никак у нормальных людей есть opcache. Что до профита "поправил и видишь результат" — опять же это актуально сегодня только при разработке (на продакшене докеры всякие), а тут время разбора не так критично (опять же opcache).

                                                                                                              0
                                                                                                              Вы забываете, что очень многие (подозреваю, что большинство), пишущих на PHP, никогда даже и не слышали о такой штуке, как opcache. Низкий порог входа — это одна из фишек языка и никто, в здравом уме, не будет замедлять парсер в два раза ради того, чтобы у вас появились удобные лично вам синтаксические конструкции.

                                                                                                              PS Почитайте, кстати, почему в Kotlin-е сделали объявления типов справа. Как-никак один из самых приятных для работы современных языков.

                                                                                                                0
                                                                                                                никогда даже и не слышали о такой штуке, как opcache

                                                                                                                но подавляющее большинство из них смогут нагуглить гайд как ускорить их любимый друпал или вордпресс где один из первых пунктов будет "установите opcache". Так что я не вижу проблемы.


                                                                                                                И да, я не считаю что в этом вопросе мнение большинства весомо.


                                                                                                                почему в Kotlin-е сделали объявления типов справа

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


                                                                                                                Так что я не понимаю вашей отсылки.

                                                                                                                  0
                                                                                                                  Популярность PHP не в малой части обусловлена его простотой и толерантностью к ошибкам и новичкам (в общем случае).
                                                                                                                  И да, я не считаю что в этом вопросе мнение большинства весомо.

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

                                                                                                                  Аргумент про «если надо, то нагуглят». Это как попытки любителей ручной коробки передач доказать, что АКПП отстой. Да, больше контроля, меньше расход (если быть профессионалом), но 1) порог входа сильно выше, 2) требует постоянного внимания и действий. А людям, в своем подавляющем большинстве, хочется просто крутить руль и жать педали «быстрее»/«медленнее», не отвлекаясь на постоянное дерганье какого-то странного рычага.
                                                                                                                  Вы так говорите, будто бы префиксная нотация это благо какое-то.

                                                                                                                  Какой-то вы странный вывод сделали. Я просто посоветовал вам посмотреть, почему так сделано, не более того. Собственно первопричиной этого решения называется облегчение синтаксического разбора кода.
                                                                                                                    0
                                                                                                                    Популярность PHP не в малой части обусловлена его простотой и толерантностью к ошибкам и новичкам (в общем случае).

                                                                                                                    и увеличение времени парсинга PHP в два раза никак на это не влияет. Не говоря о том что "в два раза" это цифра из головы, в реальности скорее всего будет меньше. Да и легко фиксится. Потому не вижу проблемы.


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

                                                                                                                    мнение можно учитывать только если оно компетентно. Иначе это не мнение даже.


                                                                                                                    Может, на самом деле, это вам нужно сменить инструмент на тот, который будет вам удобнее?

                                                                                                                    аргумент в духе "не нравится php — не пиши на нем". Он не конструктивен и бесполезен. Развивать инструменты значит не нужно?


                                                                                                                    Это как попытки любителей ручной коробки передач доказать, что АКПП отстой.

                                                                                                                    Некорректное сравнение. Начиная с того что оно не передает "если надо", заканчивая тем что никто ничего не сравнивает.


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


                                                                                                                    Ну и тут более корректно сравнение "другой АКПП". Так как подключение opcache не требует никаких дополнительных действий. Это как переключить режим коробки.


                                                                                                                    Собственно первопричиной этого решения называется облегчение синтаксического разбора кода.

                                                                                                                    в силу меньшего количества интерпритаций выражений. Это проще и для восприятия. Если бы это было не так — они бы чуть чуть заморочались, так как у них упор именно на читабельности.


                                                                                                                    Это ведь вы с потолка взяли про "в два раза дольше парсить" и на основе этого строите весь спор.


                                                                                                                    Словом, ваша позиция мне ясна, моя видимо вам тоже. Следует закругляться.

                                                                                                                      0
                                                                                                                      Это ведь вы с потолка взяли про «в два раза дольше парсить» и на основе этого строите весь спор.
                                                                                                                      Нет, это я цитировал вас.
                                                                                                                      мнение можно учитывать только если оно компетентно. Иначе это не мнение даже.
                                                                                                                      И почему вы решили, что ваше мнение более компетентно?
                                                                                                                      аргумент в духе «не нравится php — не пиши на нем».
                                                                                                                      Это не аргумент, а предположение. Если существующий инструмент вам не подходит, то вполне имеет смысл поискать более подходящий. В этом предположении нет совершенно ничего обвинительного или оскорбительного.
                                                                                                                      Если бы это было не так — они бы чуть чуть заморочались, так как у них упор именно на читабельности.
                                                                                                                      Вот нет. В кулуарах прямым текстом рассказывают, что именно простота парсера сыграла решающую роль — остальное подтянулось постфактум приятным бонусом. Также это в некоторых докладах Бреслава проскакивало (на ютубе записи с названиями а-ля «введение в Kotlin»)
                                                                                                                      Словом, ваша позиция мне ясна, моя видимо вам тоже. Следует закругляться.
                                                                                                                      ну ок
                                                                                                              0
                                                                                                              Трансляция заранее превращает интерпретируемый язык в компилируемый

                                                                                                              У меня такое впечатление, что мы говорим о разных вещах. Уже упонянутый opcache разве лишает нас каких-то преимуществ скриптовых языков?

                                                                                                                0
                                                                                                                Это только предварительная трансляция того, что можно транслировать в компайл-тайме. Опкоды потом интерпретируются.
                                                                                                                  0

                                                                                                                  Я понимаю, но проблему замедления обработки запросов из-за этапа парсинга это решает полностью. Я не понимаю теперь вообще из-за чего rjhdby упомянул это замедление.

                                                                                                                    0
                                                                                                                    Не полностью, конечно, но решает, да. Главное, по-моему, даже не в замедлении, а в усложнении транслятора.
                                                                                              0
                                                                                              То есть доллар перед переменными нужен тем, кто пользуется этими редакторами?

                                                                                              Мне нужно внести какие-то небольшие изменения в код или посмотреть на строку, в которой возникает ошибка. Я подключаюсь по ssh, ввожу nano name.php или vi name.php и читаю код. А вы мне предлагаете IDE ставить. На сервер. Который бы в консоли работал. Мне почему-то сразу хочется послать в известном направлении с такими предложениями.
                                                                                                0
                                                                                                Ну… Так то IDE умеют в удаленное подключение.
                                                                                            0
                                                                                            Почему повлияет (не про высоконагруженные, где opcache и прочие).
                                                                                            Операция компиляции происходит при каждом(!) выполнении скрипта. Эта задержка, какой бы малой она не была, добавится ко времени отклика вообще каждого скрипта. Это как раз тот случай, когда экономия на спичках оправдана.

                                                                                            Если рассматривать средней сложности приложение с десятком подгружаемых классов — умножай на количество подгружаемых файлов.

                                                                                            Парсер в PHP достаточно прямолинеен. Введение правил, которые добавят в него ветвления и дополнительные проходы приведет к непрогнозируемому росту сложности и, соответственно, времени выполнения.
                                                                                              –1
                                                                                              Операция компиляции происходит при каждом(!) выполнении скрипта. Эта задержка, какой бы малой она не была, добавится ко времени отклика вообще каждого скрипта. Это как раз тот случай, когда экономия на спичках оправдана.

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

                                                                                                0
                                                                                                opcache давно по умолчанию в PHP включается.
                                                                                                  0
                                                                                                  Включаться включается, но насколько массово используется?
                                                                                                    0

                                                                                                    в ubuntu, docker образах официальных и вроде как в centos нет. Там надо ставить отдельно.

                                                                                                      0
                                                                                                      Я про то, что включает его не надо. Если установлен, то и включен по умолчанию.
                                                                                                  0
                                                                                                  Парсер в PHP достаточно прямолинеен.

                                                                                                  это не делает его простым. Да и "ветвлений" там и сейчас не мало. Да, и уже сегодня opcache является тем самым "дополнительным проходом", который занимается устранением мертвых веток из AST, оптимизирует что может и т.д.

                                                                                                  0
                                                                                                  > Знак доллара облегчает чтение кода только если вы используете какой-то текстовый редактор типа Блокнот.

                                                                                                  Или просматриваете где-то на гитхабе. Или книгу читаете.
                                                                                                    0

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

                                                                                                      0
                                                                                                      чтобы оправдать их существование.

                                                                                                      скажите спасибо что в 2018-ом году вы можете назвать метод list или for. Доллар вам мешает.


                                                                                                      Просто учитывайте тот факт что до 2012-ого года php разбирал код очень примитивным образом. Контекстно зависимый лексинг там появился тоже не так давно и не сказать что сильно круто сделан.


                                                                                                      Сегодня проблема php — отсутствие возможности определить разницу между


                                                                                                      yield $foo => $foo ** 2;
                                                                                                      и
                                                                                                      yield ($foo => $foo ** 2);

                                                                                                      (собственно по этой причине нет коротких функций в php).

                                                                                                        0
                                                                                                        Сегодня проблема php — отсутствие возможности определить разницу между


                                                                                                        А проблема в чём? Скобки определяют группу, т.е. полноценную продукцию (ну или нетерминированную ноду AST), всё внутри парсится как отдельная структура. Получается, что первый вариант — это тупо кей-валью корутина, а второе — велью от лямбды. А ты забываешь, что там (в PHP т.е.) под капотом полноценный LALR парсер, который разруливает такие штуки «на раз-два».

                                                                                                        Мне кажется тут другая проблема. В пыхе сделали очень крутую фичу — это секцию use — явную передачу переменных в замыкание, что позволяет GC не бояться и уничтожать все остальные переменные, которые выходят за пределы скоупа (точнее у которых refcount = 0), оставляя только нужные. А в случае таких коротких лямбд — таких переменных не будет, пыху придётся захватывать весь скоуп и держать в памяти. А там и до адовых мемликов не далеко, JS уже через такое проходил. Разве нет?
                                                                                                          0
                                                                                                          под капотом полноценный LALR парсер, который разруливает такие штуки «на раз-два».

                                                                                                          как бы и да и нет. Я не могу конкретную переписку найти по поводу ограничений, но суть цирка можно описать вот этим сообщением: https://externals.io/message/88651#88836


                                                                                                          JS уже через такое проходил. Разве нет?

                                                                                                          автоимпорт если и будет то только по значению.

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

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

                                                                                                            +2
                                                                                                            Да, действительно что-то выделяет. Но хорошо заметно это только при полном просмотре файлов, на diff, с которіми я обічно и работаю, гораздо хуже заметно.
                                                                                                  0
                                                                                                  Мне в js наоборот странно когда возле переменной ничего нет, а набирание постоянных let вообще напрягает.
                                                                                                  И вообще, если $ все не замечают и никого не напрягает — значит знак выбран удачно. Конечно, кому-то может и не зайти. Я все жду когда для php появятся свой babel и тогда заживем. И вы сможете не писать $)
                                                                                            +1
                                                                                            А в некоторых не только не обходятся с $, но еще и @# юзают… Для переменных :-)
                                                                                            0
                                                                                            на счёт $ под точно проблема вылезет в том, что в строке "..." не понятно как искать переменную

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


                                                                                            А по -> — это переписать весь существующий код на PHP, и это не Java, где что-то скомпилировать можно и старым компилятором, тут вообще все умножится на ноль

                                                                                            Я бы предложил оставить старый код как есть, а в файлах с новым кодом добавить директиву, наподобии "use strict" в javascript. При использовании этой директивы для получения поля объекта надо было бы использовать точку, а для конкатенации какой-нибудь другой символ. Можно даже ->, лично у меня возражений нет :). Но лучше, конечно, какой-нибудь один символ.


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

                                                                                              0
                                                                                              Проблему -> решила бы клавиатура с настраиваемыми клавишами.
                                                                                                0

                                                                                                Мне кажется, что единодушие есть )))
                                                                                                Есть просто и понимание к каким проблемам это может привести.

                                                                                              +1

                                                                                              Вы, наверное, и переменные называете a, b и с, чтобы сэкономить?

                                                                                                0

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


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

                                                                                                +1

                                                                                                Лично мне (подчеркиваю эти два слова) знак доллара перед именем переменной гораздо удобнее — и с точки зрения читаемости, и с точки зрения всяких фишек типа подстановки значения переменной в строках в двойных кавычках. Не вижу ни малейшего смысла знак доллара убирать.
                                                                                                А вот насчет точки вместо стрелочки — оно можно, но ничего хорошего (в отличие, например, от дженериков) в язык это не принесет. А вот с конкатенацией и оператором ".=" будут проблемы. Так что пусть уж лучше будет привычная стрелочка:)

                                                                                                  0
                                                                                                  Лично мне (подчеркиваю эти два слова) знак доллара перед именем переменной гораздо удобнее — и с точки зрения читаемости

                                                                                                  Если есть IDE, она подсветить переменные каким-нибудь цветом. Если без IDE, то знак доллара действительно приносит определённую пользу.


                                                                                                  и с точки зрения всяких фишек типа подстановки значения переменной в строках в двойных кавычках

                                                                                                  Эту функцию знака доллара можно оставить.

                                                                                                  +3
                                                                                                  Значок $ перед переменными это очень удобно для того чтобы отличать переменную от функции и это как раз выгодно отличает php от многих других языков
                                                                                                    0
                                                                                                    Да, пользователи других языков очень страдают по этому поводу, даже придумали хак: договорились начинать все переменные с $. Все так делают… потому что удобно.
                                                                                                      0
                                                                                                      На JS походу так делают только для объектов JQuery, на остальных и вовсе не замечал.
                                                                                                        0
                                                                                                        Судя по всему, это был сарказм.
                                                                                                  –2
                                                                                                  В C# все это давно есть.
                                                                                                    +1

                                                                                                    А в бейсике нужно нумеровать строки десятками. И что, какое это отношение имеет к будущему PHP?

                                                                                                      0
                                                                                                      Разве не любыми числами? По-моему, десятками было просто общепринято, типа кодстайл)
                                                                                                        0
                                                                                                        Разве не любыми числами? По-моему, десятками было просто общепринято, типа кодстайл)

                                                                                                        Да, Вы правы. Подойдет любое число. Десятками нумеровали, чтобы была возможность добавить ы последующем строки в программу без тотальной перенумерации:)

                                                                                                          0
                                                                                                          Да и не в любом бейсике нумерация нужна, если уж на то пошло.

                                                                                                          Десятками нумеровали для того, чтобы можно было, при необходимости, вставить строки без пересчета всех меток до конца файла.
                                                                                                      +1

                                                                                                      Ещё нужно знак доллара поменять на знак евро, ну или рубля.


                                                                                                      В общем, завязывайте со спиртным ;-)

                                                                                                        +3
                                                                                                        Так и представляю: где-нибудь в php.ini

                                                                                                        ; Okay, guys, now you can choose your favorite currency
                                                                                                        ; $variable
                                                                                                        ; €variable
                                                                                                        ; ₽peremennaya
                                                                                                        developer.loved_currency_symbol = $
                                                                                                        0
                                                                                                        Вот ещё вспомнилось: autoload для функций
                                                                                                          0

                                                                                                          Функции, работающие с массивами, не меняют исходный массив, за некоторым исключением. Вы считаете что методы вида $arr->map(...) и $arr->filter(...) должны следовать исходной семантике, или должны менять исходный массив, на котором они вызываются?


                                                                                                          • Если первое, то значит ли что ваше API всегда нужно будет использовать вызывая методы по цепочке?..
                                                                                                          • Если второе, то каким образом, вы считаете, пользователь вашего API сможет сохранять исходный массив, если объекты в PHP по умолчанию передаются по ссылке? Всегда использовать clone при присвоении массивов?..

                                                                                                          В том числе из-за таких вопросов мы до сих пор используем array_map, а не делаем composer install ... и используем какую-то библиотеку, реализующую подобный функционал, даже не смотря на то, что такие библиотеки уже есть. Они просто неудобны в использовании, потому подобного функционала вы не увидите в самом языке.

                                                                                                            0

                                                                                                            Ну как они могут менять? Это же элементы функционального программирования, там вообще ничего не меняется.

                                                                                                              0
                                                                                                              Есть RFC о иммутабельных объектах, тут они очень в тему будут. Но, вероятно, для эффективной работы нужны будут оптимизации как раз чтобы не делать clone на каждую операцию.
                                                                                                                0

                                                                                                                Признаться честно даже если такие массивы будут иммутабельные, это нисколько не сделает PHP как язык лучше, а наоборот — сделает работу с массивами ещё сложней и запутанней, чем она уже есть.


                                                                                                                Например, сейчас ты вызываешь функцию и получаешь результат. Плохая или хорошая функция, всё очень понятно и однозначно.


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

                                                                                                                  0
                                                                                                                  С результатом сейчас не всё однозначно, даже если ограничиться семейством функций array_*.
                                                                                                                    0

                                                                                                                    Не обязательно однозначно, но предсказуемо. Достаточно запомнить как работает конкретная функция, не нужно держать в голове ещё какие-то концепты.

                                                                                                                      0
                                                                                                                      Тут достаточно будет запомнить одно правило: применение оператора -> к скаляру или массиву всегда будет возвращать новое значение, а не менять существующее.
                                                                                                                        0

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

                                                                                                                0
                                                                                                                В принципе, можно используя немножко черной магии сделать как-то так уже сейчас:
                                                                                                                $b = Array::asort($a, SORT_REGULAR); // получаем новый массив
                                                                                                                $a->asort(SORT_REGULAR); // меняем имеющийся массив
                                                                                                                

                                                                                                                Правда даже хуже чем уродливый код будет отсутствие возможности сделать нормальные подсказки для IDE, или я чего-то не знаю о возможностях докблоков.
                                                                                                                  0
                                                                                                                  Всегда выше переменной можно написать пояснение:
                                                                                                                  /** @var \Class $item */
                                                                                                                  $item->get();
                                                                                                                  
                                                                                                                    0
                                                                                                                    Немного не эти подсказки, а те — которые определяются докблоком в классе перед методом и используются для автодополнения. Я не знаю как можно объявить что для обычного вызова будет N аргументов и возврат self/void (по вкусу), а для статического вызова будет N+1 аргументов и возврат нового объекта класса.
                                                                                                                      0
                                                                                                                      Вот так можно:
                                                                                                                      /**
                                                                                                                       * @method static someClass get_by_user_id(int $id) Bla-bla
                                                                                                                       * @method static someClass get_first_by_id(int $id) 
                                                                                                                       */
                                                                                                                      abstract class a {
                                                                                                                      ...
                                                                                                                        0
                                                                                                                        И oxidmod — классная фича, запомню, но все равно не работает как я предлагал — она позволяет определить параметры для методов с разным именем, но не для одного метода который может быть вызван и статически и нет.
                                                                                                                        Короче вот так не работает:
                                                                                                                        /**
                                                                                                                         * @method static void method(DocBlockTestClass $newThis, int $arg1, int $arg2)
                                                                                                                         * @method void method(int $arg1, int $arg2)
                                                                                                                         */


                                                                                                                        Ну в принципе и фиг с ним, такое двойное использование одного метода с плавающим количеством аргументов и разным контекстом все равно ересь (пока разработчики языка не объявят обратное).
                                                                                                                          0
                                                                                                                          Не статический метод вызвать статически нормально и не поулчится.
                                                                                                                          Deprecated: Non-static method Test::method() should not be called statically
                                                                                                                            0
                                                                                                                            можно используя немножко черной магии сделать
                                                                                                                            Торжественно клянусь, что замышляю только шалость! Как я уже упоминал — работает, но уродливо до невозможности.
                                                                                                                            ужаснуться
                                                                                                                            class ArrayObj {
                                                                                                                            
                                                                                                                                public $lArray = [];
                                                                                                                            
                                                                                                                                public function __construct($array) {
                                                                                                                                        $this->lArray = $array;
                                                                                                                                }
                                                                                                                            
                                                                                                                                public static function __callStatic($name, $arguments) {
                                                                                                                                    if ($name === 'asort') {
                                                                                                                                        $newArray = clone($arguments[0]);
                                                                                                                                        $newArray->doAsort($arguments[1]);
                                                                                                                            
                                                                                                                                        return $newArray;
                                                                                                                                    }
                                                                                                                                }
                                                                                                                            
                                                                                                                                public function __call($name, $arguments) {
                                                                                                                                    if ($name === 'asort') {
                                                                                                                                        $this->doAsort($arguments[0]);
                                                                                                                            
                                                                                                                                        return;
                                                                                                                                    }
                                                                                                                                }
                                                                                                                            
                                                                                                                                private function doAsort($type = SORT_REGULAR) {
                                                                                                                                    \arsort($this->lArray, $type);
                                                                                                                                }
                                                                                                                            }
                                                                                                                            
                                                                                                                            $a1 = new ArrayObj(["d" => "lemon", "a" => "orange", "b" => "banana", "c" => "apple"]);
                                                                                                                            var_dump($a1->lArray); // ["d" => "lemon", "a" => "orange", "b" => "banana", "c" => "apple"]
                                                                                                                            $a1->asort(SORT_REGULAR);
                                                                                                                            var_dump($a1->lArray); // ["a" => "orange", "b" => "banana", "c" => "apple", "d" => "lemon"]
                                                                                                                            
                                                                                                                            
                                                                                                                            $a2 = new ArrayObj(["d" => "lemon", "a" => "orange", "b" => "banana", "c" => "apple"]);
                                                                                                                            $a3 = ArrayObj::asort($a2, SORT_REGULAR);
                                                                                                                            var_dump($a2->lArray); // ["d" => "lemon", "a" => "orange", "b" => "banana", "c" => "apple"]
                                                                                                                            var_dump($a3->lArray); // ["a" => "orange", "b" => "banana", "c" => "apple", "d" => "lemon"]
                                                                                                                            

                                                                                                                            0
                                                                                                                            Мне phpstorm пишет что нельзя определять функции с одинаковым именем в пределах одного класса, даже если одна из них статическая. Что в docblock, что в самом классе.

                                                                                                                            Fatal error: Cannot redeclare Test::method()
                                                                                                                              0
                                                                                                                              __callStatic и(или) __call
                                                                                                                        0
                                                                                                                        Вы об этом?

                                                                                                                        /**
                                                                                                                         * @method static void staticMethod(DocBlockTestClass $newThis, int $arg1, int $arg2)
                                                                                                                         * @method void method(int $arg1, int $arg2)
                                                                                                                         */
                                                                                                                        class DocBlockTestClass {
                                                                                                                        
                                                                                                                            /**
                                                                                                                             * @inheritDoc
                                                                                                                             */
                                                                                                                            public static function __callStatic($name, $arguments)
                                                                                                                            {
                                                                                                                                if ($name === 'staticMethod') {
                                                                                                                                    $arguments[0]->method($arguments[1], $arguments[2]);
                                                                                                                        
                                                                                                                                    return;
                                                                                                                                }
                                                                                                                        
                                                                                                                                throw new \BadMethodCallException('Unknown static method call.');
                                                                                                                            }
                                                                                                                        
                                                                                                                            /**
                                                                                                                             * @inheritDoc
                                                                                                                             */
                                                                                                                            public function __call($name, $arguments)
                                                                                                                            {
                                                                                                                                if ($name === 'method') {
                                                                                                                                    $this->doMethod($arguments[0], $arguments[1]);
                                                                                                                        
                                                                                                                                    return;
                                                                                                                                }
                                                                                                                        
                                                                                                                                throw new \BadMethodCallException('Unknow method call.');
                                                                                                                            }
                                                                                                                        
                                                                                                                            /**
                                                                                                                             * @param int $arg1
                                                                                                                             * @param int $arg2
                                                                                                                             */
                                                                                                                            private function doMethod(int $arg1, int $arg2): void
                                                                                                                            {
                                                                                                                                \var_dump($arg1, $arg2);
                                                                                                                            }
                                                                                                                        
                                                                                                                        }


                                                                                                                        Статический и обычный
                                                                                                                    +3
                                                                                                                    Внутренняя несогласованность в PHP вызвана тем, что язык долгое время развивался людьми, который не имели четкого представления о дизайне языка, а зачастую вообще не понимали, что они делают. Автор статьи продолжает эту традицию.

                                                                                                                    Язык может быть востребован по нескольким причинам: он предлагает уникальное решение для некой задачи, или же имеет большую кодовую базу. Изначально PHP опирался на первый пункт и был самым простым языком для написания веб-страниц, но тогда веб был совсем другим: никто не заботился о безопасности и поддерживаемости, важнее всего была возможность что-то слепить по-быстрому. Именно поэтому в языке изначально были такие секьюрити-дыры, как register_globals и magic_quotes_gpc. Теперь же удобных для бэкенда языков не меньше дюжины, но у PHP остается преимущество в виде огромного числа написанных на нем приложений и специалистов разного уровня.

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

                                                                                                                    В отличие от фронтенда, где исторически существует только JS, на бэкенде есть огромный выбор. Почти всем пожеланиям автора отвечают, например, уже существующие Typescript/C#/Java 8. Не стоит зацикливаться на одном инструменте, когда требуемую задачу лучше решает другой.
                                                                                                                      0
                                                                                                                      Ну, у PHP останется, как минимум, его модель выполнения в самом популярном случае использования. Да и изменения можно вводить постпенно, не ломая BC сразу, а делая некоторые фичи сначала просто нерекомендуемыми, потом deprecated, а уж потом выпиливать совсем. Например, в 8.0 добавить новое, а существующее на уровне документации объявить нерекомендуемым, в 9.0 сделать deprecated, в 10.0 выпилить.
                                                                                                                        0

                                                                                                                        Можно старые функции оставить, пометить как deprecated, а новое по-человечески запихивать в namespace'ы, а не в глобальную область видимости

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

                                                                                                                          private static function parseMethodName($token): string {
                                                                                                                              return trim(strrchr(rtrim($token, "\n\r\t */"), ' '));
                                                                                                                          }

                                                                                                                          Превратится в такое, например :)
                                                                                                                          private static function parseMethodName($token): string {
                                                                                                                              return standard\string\trim(standard\string\strrchr(standard\string\rtrim($token, "\n\r\t */"), ' '));
                                                                                                                          }
                                                                                                                            0

                                                                                                                            Любые функции можно импортировать через use, как и классы. Поэтому, это опять же не проблема.

                                                                                                                              0
                                                                                                                              Вы можете объективно описать недостатки присутствия этих функций в конревом пространстве имен?
                                                                                                                                0
                                                                                                                                Ага, а потом список импортов занимает пол файла.
                                                                                                                                  0

                                                                                                                                  если так — то может стоит задуматься почему у вас такое разнообразие зависимостей используется? Ну и всегда можно сделать так:


                                                                                                                                  use function \{strlen, strpos, array_map, array_reduce};
                                                                                                                                    0
                                                                                                                                    Дело же часто не в количестве зависимостей как таковых. Очень многими чистые функции стандартной библиотеки и популярных расширений вообще как зависимости не рассматриваются.
                                                                                                                                0