Тут проблема в том, что PHP не только язык, но и платформа — как бы вы отнесличь, если бы рабочие сделали бы вам дом, к коророму надо подводить воду треугольных трубах. Причем сами треугольные ьрбы гораздо круче, только вот их можно купить только японского производства.
Для решения этой проблемы у Fog Creek даже свой язык есть с генератором PHP
по-моему у них дохренища общего. Например, то, что они список. Можно написать шаблон для всех списков, который будет показывать в унифиуированном виде: заголовок, строки, причем четные сервм, нечетные белым фоном, футер, кнопки для редактирования, пейджинг и прочее.
>>>Т.е. если меня в целом устраивает PHP, и я не вижу ниаких особых «неряшливых концепций» — я, по вашей оценке, «нетребовательный лох»?
Я говорил не о свой оценке, а о подходе авторов стандартной библиотеки.
>>>Требовать от языка такой популярности моментального реагирования на все новые тенденции и пожелания, особенно такие, что затрагивают базовую организацию и нарушают работу всего существующего софта — это безумие
Есть другой подход — доабвить например новые возможности, на старые написать предупреждения и постепенно привести в стройность то, что есть. Я не знаю, есть ли в PHP концепция depreciated как в java и python
Насколько я знаю, вы смотрели в сторону python и можете сами сравнить, насколько обобщенный код можно написать там и там — я php смотрел несколько лет назад и то, что я увидел, мне сильно не понравилось.
во-первых, это просто пример. Можно привести в пример itertools и functools как часть того, что можно сделать еще.
во-вторых, можно, например, генерировать интерфейс на основе общих правил, типа «html представление списка объектов — это html представление оъектов, заключенные в li». Чтобы не хардкодить каждую страничу по своему, грубо говоря (ну там придется не зардкодить это li, а обратиться к микрошаблону)
Я думаю, вы просто не смотрели пока на код с этой точки зрения — представьте себе что практически все функции, которые работают с массивами работают и со строками и с последовательностями сгенерированными ORM и другими вещами, которые можно представить как последовательность — и этих функций много (например см. модуль itertools)
>>>Не очевидно, что при передачи строки «abc» в такую функцию в результате будет список из трёх элементов.
Почему? Если вы согласились, что строка концептуально — массив символов, то почму передача такого массива в функцию, которая представляет последовательность в виде списка, не должна преставить эту конкретну последовательность в виде html списка? По-моему это логично, абстрактно и мощно
ну то есть вы явно создаете ассоциатиынй массив только указываете, что это ассоциативный массив другим образом?
Реальная необходимость — вон например код из моего примера работает только с последовательностями строк. Сделаем чтоб оно работало со всем, что можно представить как строку:
def make_list(xs):
return ''.join('<li>'+str(x)+'</li>' for x in xs)
print make_list(xrange(0, 10))
Для решения этой проблемы у Fog Creek даже свой язык есть с генератором PHP
Я говорил не о свой оценке, а о подходе авторов стандартной библиотеки.
>>>Требовать от языка такой популярности моментального реагирования на все новые тенденции и пожелания, особенно такие, что затрагивают базовую организацию и нарушают работу всего существующего софта — это безумие
Есть другой подход — доабвить например новые возможности, на старые написать предупреждения и постепенно привести в стройность то, что есть. Я не знаю, есть ли в PHP концепция depreciated как в java и python
во-вторых, можно, например, генерировать интерфейс на основе общих правил, типа «html представление списка объектов — это html представление оъектов, заключенные в li». Чтобы не хардкодить каждую страничу по своему, грубо говоря (ну там придется не зардкодить это li, а обратиться к микрошаблону)
Почему? Если вы согласились, что строка концептуально — массив символов, то почму передача такого массива в функцию, которая представляет последовательность в виде списка, не должна преставить эту конкретну последовательность в виде html списка? По-моему это логично, абстрактно и мощно
implode с этим итератором будет работать?
Реальная необходимость — вон например код из моего примера работает только с последовательностями строк. Сделаем чтоб оно работало со всем, что можно представить как строку:
codepad.org/dRTXxV1U
Теперь оно работает вообще со всеми объектами, у которых есть метод __str__ включая встроенные
•Могу ли я использовать API Яндекс.Карт в приложениях, не являющихся интернет-сервисами?
Нет, это запрещено Пользовательским соглашением.