Только ленивый, точнее, ну очень ленивый не скажет про PHP пару ласковых. Стоит мимолётом покритиковать разработчиков за то, что больше половины попыток исправить ситуацию с фаршированием стандартной библиотеки, несогласованности и отсутствием того, что очень сильно понравилось в *подставить свой любимый язык* только её (ситуацию) ухудшают, а те, что влияют положительно — не доработаны; Конечно же это провокация и ведёт к неизбежному холивару, но давайте постараемся избежать этого. Из довольно продолжительных размышлений на эту тему и родилась одна затея…
Скажите, а ведь вы хотите что-то изменить в языке, поправить? Знакомясь с новыми языками и подходами, лично у меня — эта мысль крепла. Я испробовал довольно много подходов, начиная от попытки написать собственный интерпретатор, не обладая достаточными знаниями — попытка провалилась, заканчивая переписыванием php исходников (не интерпретатора, а самих *.php файлов) — вначале нативный интерпретатор парсит изменённые исходники, затем транслирует в код\сохраняет данные и уже их интерпретирует, но, добившись определённых результатов — и эта попытка была погребена благодаря своему неудобству и «костылеобразности». И, уже почти разочаровавшись в этой затее — мне помог докладчик на DevConf (если не ошибаюсь — Александр NightTiger), сам того не подозревая. Доклад был про аспектно-ориентированное программирование и одной из просьб докладчика, которая и подтолкнула меня на правильный путь, была: «Поднимите руки те, кто знает про php фильтры».
Немного покопавшись в мануале, перечитав исходники Aspect фреймворка (их, к слову, на гитхабе нашлось несколько — совершенно разных), погуглив — я наконец пришёл к тому результату, которого я ждал — «Эврика!», воскликнул я. Дело осталось за малым, набросать на коленке за пару часов рабочий код и дело было в шляпе — всё о чём мечтал — свойства, перечисления, именованные параметры, нормальное приведение типов и много чего ещё, всё что можно вообразить, без расширений, без костылей и геморроя — вот оно счастье! То, на что я потратил несколько месяцев раздумий, попыток написать что-то и сотни струнок нервов из нержавейки — неужели мечта, так бережно лелеянная мною скоро воплотится? Каково же было моё удивление, когда мой «говнокод» (да простит меня общество за столь непристойный термин) действительно заработал, и даже так, как я почти хотел.
Далее следовало:
1) Написание плана (роадмапа) проекта
2) Полное переписывание того двухчасового ужаса, что я набросал
3) Исследование комьюнити. Мнения, пожелания, взлетит\нафиг_оно_надо
С первым было больше всего проблем, я остановился на варианте встраивания того, что полностью совместимо с языком — по-умолчанию. Все указания типов в параметрах, свойства и прочее-прочее должны быть доступны сразу — оно не ломает ничуть обратную совместимость, для остального же решил использовать подход, похожий на питон — конструкцию import, которая указывает:
где «ЧТО» — название файла\класса согласно спецификации PSR-0, а «ГДЕ» — указание на набор пакетов, будь то стандартные, либо добавленные\написанные пользователем вручную. Текущий вариант стандартных пакетов включает в себя:
где draft — уже сделанное и более-менее готовое к употреблению, а todo — только на этапе разработки\переписывания\обсуждений.
Второй пункт тоже вполне получился. Исходники довольно приятные (я считаю, сильно не бейте :D) на ощупь: github.com/SerafimArts/Mirror
И наконец под третьим пунктом — интересно именно ваше мнение, уважаемое хабрасообщество.
Вместо послесловия хочу отметить:
— На данный момент полностью готово ядро.
— Реализовано приведение типов в параметрах методов\функций github.com/SerafimArts/Mirror/wiki/Type-Casting включая рабочий пример: github.com/SerafimArts/Mirror/blob/master/examples/TypeCasting/test.php
— Нет юнит-тестов
— Нет документации, но есть полностью документированный код
— Отсутствует установка через Composer
— Зато есть собранный phar пакет
Использование:
и внутри подключённого с помощью функции require_mirror (либо include_mirror) файла, включая абсолютно все внутренние инклуды (даже с помощью стандартных функций) будет возможность использовать синтаксис Mirror — именно так я назвал данное поделие — как отражение языка, а пакеты — стёкла или призмы (Glass) с помощью которых можно изменять язык.
В последующих статьях (если они всё же случатся) я хочу ознакомить вас с внутренним устройством библиотеки — как написать свою «призму», как работает кеширование, подробными планами на будущее и ещё чем-нибудь, что вас заинтересует. Проект довольно сырой (был написан за время отпуска на чёрном море — сами понимаете), так что статья нацелена именно на ваши отзывы и пожелания, что бы заранее не накосячить с разработкой. Спасибо большое за внимание.
UPD: Поправил английский перевод слова «стёкла»
Скажите, а ведь вы хотите что-то изменить в языке, поправить? Знакомясь с новыми языками и подходами, лично у меня — эта мысль крепла. Я испробовал довольно много подходов, начиная от попытки написать собственный интерпретатор, не обладая достаточными знаниями — попытка провалилась, заканчивая переписыванием php исходников (не интерпретатора, а самих *.php файлов) — вначале нативный интерпретатор парсит изменённые исходники, затем транслирует в код\сохраняет данные и уже их интерпретирует, но, добившись определённых результатов — и эта попытка была погребена благодаря своему неудобству и «костылеобразности». И, уже почти разочаровавшись в этой затее — мне помог докладчик на DevConf (если не ошибаюсь — Александр NightTiger), сам того не подозревая. Доклад был про аспектно-ориентированное программирование и одной из просьб докладчика, которая и подтолкнула меня на правильный путь, была: «Поднимите руки те, кто знает про php фильтры».
Немного покопавшись в мануале, перечитав исходники Aspect фреймворка (их, к слову, на гитхабе нашлось несколько — совершенно разных), погуглив — я наконец пришёл к тому результату, которого я ждал — «Эврика!», воскликнул я. Дело осталось за малым, набросать на коленке за пару часов рабочий код и дело было в шляпе — всё о чём мечтал — свойства, перечисления, именованные параметры, нормальное приведение типов и много чего ещё, всё что можно вообразить, без расширений, без костылей и геморроя — вот оно счастье! То, на что я потратил несколько месяцев раздумий, попыток написать что-то и сотни струнок нервов из нержавейки — неужели мечта, так бережно лелеянная мною скоро воплотится? Каково же было моё удивление, когда мой «говнокод» (да простит меня общество за столь непристойный термин) действительно заработал, и даже так, как я почти хотел.
Для затравки:
<?php
import Accessors, Enum, Properties from std;
namespace Ololo
{
enum Color
{
Red,
Blue,
Green,
Yellow
}
class Some
{
private:
$asdasd = 23;
$some = 42;
public $some
{
get;
set($value)
{
return (int)$value + 42;
}
}
public function __construct()
{
echo Color::Red . \Ololo\Color::Blue;
}
}
}
Далее следовало:
1) Написание плана (роадмапа) проекта
2) Полное переписывание того двухчасового ужаса, что я набросал
3) Исследование комьюнити. Мнения, пожелания, взлетит\нафиг_оно_надо
С первым было больше всего проблем, я остановился на варианте встраивания того, что полностью совместимо с языком — по-умолчанию. Все указания типов в параметрах, свойства и прочее-прочее должны быть доступны сразу — оно не ломает ничуть обратную совместимость, для остального же решил использовать подход, похожий на питон — конструкцию import, которая указывает:
import ЧТО from ПАКЕТ;где «ЧТО» — название файла\класса согласно спецификации PSR-0, а «ГДЕ» — указание на набор пакетов, будь то стандартные, либо добавленные\написанные пользователем вручную. Текущий вариант стандартных пакетов включает в себя:
Сам список:
* draft Приведение типов
* todo function __init — автоматически вызываемый метод при инициализации класса (require файла с ним)
* todo Свойства
* todo Перечисления
* todo Аспекты
* todo Именованные параметры
* todo Упрощенное объявление области видимости свойств\методов
* todo Стандартизация всех функций и вынос их в отдельные пространства
* todo Скаляры в виде объектов
* todo function __init — автоматически вызываемый метод при инициализации класса (require файла с ним)
* todo Свойства
* todo Перечисления
* todo Аспекты
* todo Именованные параметры
* todo Упрощенное объявление области видимости свойств\методов
* todo Стандартизация всех функций и вынос их в отдельные пространства
* todo Скаляры в виде объектов
где draft — уже сделанное и более-менее готовое к употреблению, а todo — только на этапе разработки\переписывания\обсуждений.
Второй пункт тоже вполне получился. Исходники довольно приятные (я считаю, сильно не бейте :D) на ощупь: github.com/SerafimArts/Mirror
И наконец под третьим пунктом — интересно именно ваше мнение, уважаемое хабрасообщество.
Вместо послесловия хочу отметить:
— На данный момент полностью готово ядро.
— Реализовано приведение типов в параметрах методов\функций github.com/SerafimArts/Mirror/wiki/Type-Casting включая рабочий пример: github.com/SerafimArts/Mirror/blob/master/examples/TypeCasting/test.php
— Нет юнит-тестов
— Нет документации, но есть полностью документированный код
— Отсутствует установка через Composer
— Зато есть собранный phar пакет
Использование:
<?php
require('phar://mirror.phar'); // или "lib/Mirror/bootstrap.php"
require_mirror('path\to\file.php');
и внутри подключённого с помощью функции require_mirror (либо include_mirror) файла, включая абсолютно все внутренние инклуды (даже с помощью стандартных функций) будет возможность использовать синтаксис Mirror — именно так я назвал данное поделие — как отражение языка, а пакеты — стёкла или призмы (Glass) с помощью которых можно изменять язык.
В последующих статьях (если они всё же случатся) я хочу ознакомить вас с внутренним устройством библиотеки — как написать свою «призму», как работает кеширование, подробными планами на будущее и ещё чем-нибудь, что вас заинтересует. Проект довольно сырой (был написан за время отпуска на чёрном море — сами понимаете), так что статья нацелена именно на ваши отзывы и пожелания, что бы заранее не накосячить с разработкой. Спасибо большое за внимание.
UPD: Поправил английский перевод слова «стёкла»
