Если с автокомплитом, то это уже «IDE», а вот если «без», то я восхищаюсь, ибо помнить тысячи классов и десятки тысяч методов это действительно круто (без сарказма).
> Неоднократно слышал от джавистов что на джава писать без IDE невозможно.
Совсем по другой причине — API (как и сами проекты) гораздо больше и сложнее, запомнить все невозможно. Впрочем, ни один большой проект на PHP тоже невозможно полноценно разрабатывать без современной IDE.
> Это к тому, что XML никогда в качестве формата конфигурации/описания пакетов не работал.
ivy (http://ant.apache.org/ivy/), maven (http://maven.apache.org/) и др. проекты с вами не согласны.
> Смотрим на PEAR — каждый крупный проект писал скрипт для билда xml описания пакета
Для генерации XML файлов, есть XMLWriter (http://ru2.php.net/XMLWriter), который довольно сильно это упрощает (особенно если добавить пару методов для добавления массивов элементов и атрибутов).
Насчет конфигов — нужно различать данные, которые предназначены для редактирования пользователем (описание пакета и зависимостей) и служебные данные (список того что установлено, откуда уставлено и т.д.).
Для второго типа данных можно использовать любой формат, т.к. никто кроме программы (и в редких случаях её разработчика) эти файлы читать не будет. Можно даже, отказать от их проверки в программе (если кто-то криворукий догадается их «поправить» — это его проблемы).
А вот со вторым приходится работать обычным пользователям => необходима проверка этого файла (велосипед) и вот в этом случае XML схема отличнейший вариант, причины см. в моем первом комментарии (http://habrahabr.ru/post/145946/#comment_4910138) (намекну – вся проверка сведется к вызову «DOMDocument::schemaValidate»)
> DSL на чистом PHP
Тоже, кстати, неплохой вариант, и будет работать даже если нет поддержки XML (это можно было привести в качестве более реального недостатка XML), и так же как и схема упростил бы написание конфигов (автокомплит) и избавил бы от необходимости смотреть в документацию (phpdoc). Правда сваять на коленке нормальный DSL уже не получится.
Насчет «сотен мегабайт оператива» — бред (а тот небольшой оверхед который будет — совсем не критичен для инструмента разработки). Если вам удобно постоянно смотреть документацию, а без этого написать конфиг невозможно и нравится постоянно писать велосипеды для проверки структуры этих файлов — удачи. Я же предпочту переложить это на используемый инструмент.
Какой-то json головного мозга… Лучше бы минут за 20 накидали XML схему и получили в качестве бонусов легкость написания конфигов (все нормальные XML редакторы отлично работают со схемами) и простоту их проверки в софте.
> Я понимаю риски использования float и всегда предупреждаю о них заказчиков
Они и не могут ничего сказать, т.к. не понимают (и не должны понимать) и им все равно (у них задачи совсем другие и им некогда вникать во все это).
> Отсутствие денежного формата — однозначно минус языка.
Использовать несколько функций вместо операторов не настолько сложно чтобы забивать на это. Да и класс при желании можно найти/написать.
> Не поверите, можно привести к float и сравнить через "===".
Ага, отличная мина на будущее, кстати (в случае с ценами).
На самом деле написание собственной ORM отлично прокачивает скил проектирования, особенно если уйти в сторону от ActiveRecord и прочитать в процессе разработки соответствующую литературу (для начала, «шаблоны корпоративных приложений», потом может и на UML потянет и т.д.).
Безусловно, библиотеки нужны, но знать как они устроены и быть способным при необходимости написать что-то большее гораздо важнее для профессионального программиста. Кроме того, развитая способность к разработке чего то нестандартного позволит перейти на уровень выше и стать проектировщиком, с этого момента часть скучной и неинтересной работы по написанию очевидного кода (= рутины) можно переложить на тех кто в это время полностью освоил какой либо разработанный вами framework :)
Поэтому изучение одного framework-а, который все делает за вас, считаю тупиковым, т.к. он ведет к отмиранию способности проектировать что-то большее чем набор контроллером в моделей (если это вообще можно считать проектированием). И кстати, тут на хабре где-то год назад наверное проскакивал топик/вопрос от человека который пошел по пути потребления и в итоге обнаружил, что стал не способен создать ничего нового. Найти не смог, к сожалению.
Если с автокомплитом, то это уже «IDE», а вот если «без», то я восхищаюсь, ибо помнить тысячи классов и десятки тысяч методов это действительно круто (без сарказма).
Совсем по другой причине — API (как и сами проекты) гораздо больше и сложнее, запомнить все невозможно. Впрочем, ни один большой проект на PHP тоже невозможно полноценно разрабатывать без современной IDE.
ivy (http://ant.apache.org/ivy/), maven (http://maven.apache.org/) и др. проекты с вами не согласны.
> Смотрим на PEAR — каждый крупный проект писал скрипт для билда xml описания пакета
Для генерации XML файлов, есть XMLWriter (http://ru2.php.net/XMLWriter), который довольно сильно это упрощает (особенно если добавить пару методов для добавления массивов элементов и атрибутов).
Насчет конфигов — нужно различать данные, которые предназначены для редактирования пользователем (описание пакета и зависимостей) и служебные данные (список того что установлено, откуда уставлено и т.д.).
Для второго типа данных можно использовать любой формат, т.к. никто кроме программы (и в редких случаях её разработчика) эти файлы читать не будет. Можно даже, отказать от их проверки в программе (если кто-то криворукий догадается их «поправить» — это его проблемы).
А вот со вторым приходится работать обычным пользователям => необходима проверка этого файла (велосипед) и вот в этом случае XML схема отличнейший вариант, причины см. в моем первом комментарии (http://habrahabr.ru/post/145946/#comment_4910138) (намекну – вся проверка сведется к вызову «DOMDocument::schemaValidate»)
> DSL на чистом PHP
Тоже, кстати, неплохой вариант, и будет работать даже если нет поддержки XML (это можно было привести в качестве более реального недостатка XML), и так же как и схема упростил бы написание конфигов (автокомплит) и избавил бы от необходимости смотреть в документацию (phpdoc). Правда сваять на коленке нормальный DSL уже не получится.
И к чему это?
А где интеграция с PEAR-ом? Она же вроде бы есть?
> «Потому что. Просто примите это.»
Какой-то json головного мозга… Лучше бы минут за 20 накидали XML схему и получили в качестве бонусов легкость написания конфигов (все нормальные XML редакторы отлично работают со схемами) и простоту их проверки в софте.
(http://habrahabr.ru/company/intel/blog/145279/#comment_4881592)
Они и не могут ничего сказать, т.к. не понимают (и не должны понимать) и им все равно (у них задачи совсем другие и им некогда вникать во все это).
> Отсутствие денежного формата — однозначно минус языка.
Использовать несколько функций вместо операторов не настолько сложно чтобы забивать на это. Да и класс при желании можно найти/написать.
> Не поверите, можно привести к float и сравнить через "===".
Ага, отличная мина на будущее, кстати (в случае с ценами).
Для некоторых (и меня в том числе) это как раз реальность…
> А как я узнаю, что стоимость товара совпадает с внесенной суммой?
Смотрите в сторону BCMath (http://ru.php.net/bcmath).
switch ('4.2') {
case '4.20':
echo 'true';
break;
default:
echo 'false';
break;
}
*даже если они странные и нелогичные* (чуть выше написано).
> Две разные строки парсятся и приводятся к числлу!
Это касается только числовых строк. («4.2a» == «4.20a») будет false
> Java
Забавный у вас подход — не очевидная особенность в java, это фича, а у php сразу косяк
(хотя и то и это задокументировано).
К счастью интересные задачи все еще встречаются.
> более перспективных профессиональных областях…
Проектирование, по вашему, недостаточно перспективно?
Безусловно, библиотеки нужны, но знать как они устроены и быть способным при необходимости написать что-то большее гораздо важнее для профессионального программиста. Кроме того, развитая способность к разработке чего то нестандартного позволит перейти на уровень выше и стать проектировщиком, с этого момента часть скучной и неинтересной работы по написанию очевидного кода (= рутины) можно переложить на тех кто в это время полностью освоил какой либо разработанный вами framework :)
Поэтому изучение одного framework-а, который все делает за вас, считаю тупиковым, т.к. он ведет к отмиранию способности проектировать что-то большее чем набор контроллером в моделей (если это вообще можно считать проектированием). И кстати, тут на хабре где-то год назад наверное проскакивал топик/вопрос от человека который пошел по пути потребления и в итоге обнаружил, что стал не способен создать ничего нового. Найти не смог, к сожалению.
Поэтому велосипедить надо, но в меру.