Обсуждение:PHP/Архив/1

Альт

Что за Альт? Почему не пояснено? Удаляю Ramir.

Влияние Java

Стоит ли писать в карточке о влиянии Java на PHP 5 (поскольку я часто слышу, что в PHP работа с объектами как в Java). — A.I. 19:11, 15 января 2007 (UTC)

Полностью согласен с добавлением, особенно актуально будет с ООП из PHP6. — Lockal 09:16, 16 января 2007 (UTC)

Многоуважаемые, PHP не создавался под влиянием Java. Я против вашего изменения. Судья 18:10, 16 января 2007 (UTC)

А PHP 5 создавался :). Всё таки язык программирование - это динамичная структура, которая постоянно изменяется... --A.I. 19:18, 16 января 2007 (UTC)

Правильно сказано… Именно создавался. Язык PHP постоянно развивается, и тогда уж надо Fortran добавить))) Как-никак и этот язык программирования оказал влияние на первую версию PHP ))). А из Java действительно ОЧЕНЬ много перетащено, и не только по части ООП-а. — Lockal 19:53, 16 января 2007 (UTC)

Вы говорите бред. PHP не создавался под влиянием Java. Советую вам заглянуть в версии Википедии на других языках, к примеру, на английском. Правку отменяю. Советую заняться дополнением статьи, а не созданием мифов. Судья 13:42, 18 января 2007 (UTC)

Читайте что говорят, разумеется PHP, как язык, не развивался под влиянием Java, однако объектная модель слизана с Java подчистую - когда говорят о влиянии Java, речь идёт только об объектно-ориентированном программировании. Cheops 13:06, 20 июля 2007 (UTC)

Cheops, ну отчего же он не развивался под влиянием Java? Отнюдь. Разве появление ООП не есть развитие PHP, как языка программирования? Я считаю, что указание Java в параметре "Создан под влиянием" не будет соответствовать действительности, но вот если бы в карточке языка программирования имелись примерно такие параметры: "Развивался под влиянием", "Оказал влияние на развитие", "Создан под влиянием", "Оказал влияние на создание", то в карточку PHP можно было бы добавить параметр "Развивался под влиянием" и указать там Java и прочие языки программирования, под влиянием которых развивался, развивается, и будет развиваться PHP, а в параметре "Создан под влиянием" оставить Perl и C(возможно, что-то ещё?) Соответственно, в карточку Java необходимо будет добавить параметр "Оказал влияние на развитие" и указать там PHP. Как вы считаете? Судья 22:29, 17 июля 2008 (UTC)

Согласен. Вообще наибольшее влияние на PHP оказал Perl (это невооруженным взглядом видно - PHP это попытка создать промышленный язык, главным образом для Web-разрботки, обладающий удобством Perl, но не поощряющий вольности перловцев). Java скорее оказала влияние на ASP.NET. PHP-разработчики (как и Perl-разработчики) вообще очень осторожно относятся к ООП - все интерфейсы в Web-среде, большинство API для баз данных процедурные и ООП-подход не всегда эффективен. Поэтому говорить о каком-то тотальном влиянии Java на PHP будет действительно не правильно - подходы и философия слишком уж разные. --Cheops 10:55, 18 июля 2008 (UTC)

Расшифровка аббревиатуры

В 1997 году было решено, что сокращение РНР должно означать не «Personal Home Page», a «PHP Hypertext Processor»*. Кем было решено? —Obersachse 08:41, 25 Апр 2005 (UTC)

Разработчиками конечно :). --A.I. 19:11, 15 января 2007 (UTC)

хм.... а я читал книгу по Dreamweaver MX, и там было написано Personal Home Page.... ну что ж... буду знать... - onX 3.03.2007

«Personal Home Page» - может пометить его как устаревшее название? 217.9.84.186 02:20, 18 января 2009 (UTC)

последний откат

Ramir а вы не могли бы реагировать на изменения чуть оперативнее? Дело в том, что вы своим откатом уничтожаете правки внесённые позже… Я не автор абзаца, но мне тоже не понравилось, чтобы была удалена история возникновения PHP. Вы бы сами не могли свои действия прокоментировать?

Язык — Программа

Непонятно, почему на странице с описанием языка находится карточка с описанием реализации…

чтобы вы предложили? ps. подписывайтесь… —tasc 19:17, 5 марта 2006 (UTC)

Между прочим реализация только одна, т. ч. это логично. --A.I. 06:35, 6 марта 2006 (UTC)

Но для PHP это не самый удачный вариант. Я бы предложил следующий вариант:

Самая полезная и простая программа на PHP:

<?php

phpinfo();

?>

—Hayk 17:43, 6 марта 2006 (UTC)

вы не правы. —tasc 18:33, 6 марта 2006 (UTC)

А я считаю что прав. —Hayk 18:44, 6 марта 2006 (UTC)

Вы собираетесь заменить HelloWorld листингом phpinfo()? Если так, что это не очень хорошо, так как 1. HelloWorld — традиций, 2. гораздо лучше показывает синтаксис. --A.I. 04:44, 7 марта 2006 (UTC)

Я не собираюсь ничего заменять. Я просто пердложил вариант самой полезной и простой программы на PHP. —Hayk 14:57, 7 марта 2006 (UTC)

Самая полезная и простая программа значительно менее полезна во вступлении к данной статье. —tasc 15:00, 7 марта 2006 (UTC)

Ошибки в статье

1 — PHP — не интерпретируемый язык. Он работает примерно так же как Java — тоесть компилируется на лету в байт-код. В интерпритируемых языках, кстати, не бывает «parse error» в момент включения файла.

Сама программа на php — это исходный текст, а не байт-код (исключая проприетарные программы закодированные Zend Safeguard). Да и «кеширование» прораммы (создание байт-кода уже на сервере для оптимизации а не дя распространения) работает только при установленном Zend Optimizer (что бывает редко на хостинге). --A.I. 08:20, 15 марта 2006 (UTC)

Сама программа на любом языке — это исходный текст. Так же и для C, но никто не называет C интерпретируемым языком(хотя интерпритаторы C существуют).А принцип работы PHP — именно компиляция на лету в байт-код и выполнение байт-кода виртуальной машиной. Что до кеширования — Optimizer далеко не единственный и далеко не лучший проект PHP акселератора.

Исходный текст программы не C — это не программа, поскольку она не может быть выполненна сразу (в отличии от PHP). Да и вы ушли от главного вопроса — если PHP компилируемый язык, то почему пользователь не имеет резульатат компиляции не руках, почему программы на php не распространяются в бинарниках? ;) Именно поэтому я настаиваю, что «байт-код» PHP — это лишь инструмент оптимизации.

К тому же сравните процесс разработки под Java (компилируемый байт-код) и под PHP. Java: написал, откомпилировал, собрал, запустил. PHP: написал, запустил. --A.I. 11:06, 16 марта 2006 (UTC)

В PHP компиляция в байт-код происходит на лету. Но это не делает языка интерпретатором. --Dime 08:43, 17 марта 2006 (UTC)

Zend Optimizer используется настолько редко, что можно практически не говорить об байт-коде применительно к PHP - в подавляющем большинстве случаев (примерно в 98% случаев), код интерпретируется непосредственно из исходных кодов. --cheops. 00:46, 22 февраля 2008 (UTC)

2 — простейная программа «Hello Word!» на PHP выглядит как текстовый файл содержащий текст «Hello Word!». А если вам нужна именно программа, то, на худой конец <?="Hello Word!"?>

2- shorttag’и это не «стандартное» средство. Простой текстовый файл — никакой hellow world показывать не будет. —tasc 08:16, 15 марта 2006 (UTC)

те нотации которые я привожу — это стандартное средство для вывода значения выражения. Читайте документацию на php.net. Или просто попробуте выполниь. --Dime

Не «нестандартное»? ;) В студию ссылку на нормальную php-программу, где такой прием применяется :) .--A.I. 11:06, 16 марта 2006 (UTC)

Что для Вас норма? Если вы потрудитесь почитать работы по оптимизайции PHP кода то вы узнаете много нового для себя :-) а мегабайты проприветарного кода пусть лучше обкажутся вне студии. --Dime 08:43, 17 марта 2006 (UTC)

Hello Word — это программа для демонстрации синтаксиса языка. Конструкции вида «<?="Hello Word!"?>» я нигде не видел, а «Hello Word!» будет не php-файлом а plain text. --A.I. 08:20, 15 марта 2006 (UTC)

Если вы чего-то не видели не значит что этого не существует. Более того, в PHP есть еще несколько способов вывода данных в stdout. А насчет plain text — все что php выполняет без возникновения исключений и есть php код. Точно так же как <php echo "Hello Word!";> может быть рассмотрено как plain text --Dime

P.S. вы еще скажите что php поддерживает два вида массивов — ассоциированные и индексированные. --Dime

Hello Word — это программа для демонстрации синтаксиса языка, поэтому желательно использовать только распространенные приемы. Между прочим plain text не будет интерпретироваться php, то есть интерпретатор пробежиться по нему, но не будет анализировать не стрчки (если в режиме CLI), а в межиме модуля Apache веб-сервер может вообще не передать файл интерпретатору. --A.I. 11:06, 16 марта 2006 (UTC)

более распространенного приема чем <?=$value?> и придумать сложно. Не говоря уже о том что методам вывода посвящены первые же страницы руководства. А именно — с этого начинается раздел основы синтаксиса. (например http://www.php.net/manual/en/language.basic-syntax.php) И если такая нотация для вас откровение — возникает вопрос — А что вы вообще знаете о PHP?

Если вы говорите, что <?=$value?> популярна, докажеите это. --A.I. 10:37, 17 марта 2006 (UTC)

Что же до пассажа «а в режиме модуля Apache веб-сервер может вообще не передать файл интерпретатору» — вероятно вы вообще не представляете о чем вы говорите. Если тип файла зарегистрирован на выходной фильтр, то Apache не сможет не передать его модулю фильтра.

Команда file -i выдает для такого файла (без <?php и т. д.) типа plain text.

Кстати разработчики php, как hello world в доках использовали как раз <?php echo ... --A.I. 10:37, 17 марта 2006 (UTC)

И последнее, еще раз — у PHP с версии 4 нет интерпретатора :-) прочитате хоть http://ua2.php.net/manual/ru/introduction.php#intro-whatis что ли. И вообще — надите слово интрепретатор в руководстве (хоть один раз). Вам не кажется что разработчикам виднее, чем вам, интерпретатор это лили нет? --Dime 08:43, 17 марта 2006 (UTC)

Я считаю, что подобный шаг - это стремление разработчиков избавиться от клейма, простенького скриптового языка для домашних страниц. Хотя с другой стороны, все таки SafeGuard не шифруют, а именно переводят в байт-код, да и стали встречаться защищенные приложения весьма часто, т. ч. лучше упоминание о интерпретируемости убрать (но не добавлять, что он компилируемый :) ). --A.I. 10:37, 17 марта 2006 (UTC)

о чём спор? Взгяните на определение интерпретатора

Хех, Dime, PHP - это «интерпретаторами компилирующего типа» :) . Хотя думаю добавлять будет уже лишнее. В PHP главное, что он для web. --A.I. 08:03, 20 марта 2006 (UTC)

PHP и MySQL. Совместная работа

Как вы относитесь к тому что я хочу создать такую темку??? "PHP и MySQL. Совместная работа" --linkovik

Я думаю лишней не будет. Ведь хорошая интеграция с БД «из коробки» в своё время очень отразилась на популярности PHP. --A.I. 12:00, 26 апреля 2007 (UTC)

Лучше статью о PHP расширить. --Cheops 13:10, 24 июля 2007 (UTC)

Я За расширение статьи Devgru 09:37, 11 ноября 2007 (UTC)

Почти за Учитывая популярность такой связки полезность статьи значительно возрастёт. Хотя по-хорошему общий раздел «PHP и различные СУБД» будет ещё полезней для читателей и нас самих :) Callidus 05:50, 25 сентября 2008 (UTC)

Недостатки/Критика

Думаю, что стоит добавить раздел "Критика" или "Недостатки", где объективно описать слабые стороны языка: скорость работы, слабая расширяемость, отсутствие ООП в базовых типах, несогласованность работы ООП в различных версиях др. У многих серьезных статей такой раздел есть: Python, Java, C++.

Вопрос состоит в том, делать ли раздел в основной статье или создать новую статью (например "Критика PHP")? В отдельной статье можно будет свободго развернуться: примеры кода, сравнение с "академическими" языками. Думаю можно много текста написать. Козырь 22:33, 27 июня 2008 (UTC)

В отдельной статье нельзя, так как ВП:ОМ. А так раздел конечно же нужен — прошу :) --A.I. 01:51, 28 июня 2008 (UTC)

Убрал раздел "Сборщик мусора" - не нужно таскать проблемы чужих языков. В PHP такой проблемы нет, на каждый скрипт выделяется строго определённое количество памяти, за который скрипт не может выйти. Проблема других языков заключается в том, что они не могут полностью освобождать память (т.е. освобождают её в виртуальную машину, почему и нужно время от времени освобождать эту память) - PHP может и осовобождает прямо в кучу (конструкция unset) - поэтому он и медленный. --Cheops 11:02, 18 июля 2008 (UTC)

Вообще раздел критики ниже всякой критики, мало того, что используется неочевидная функция range() вместо array(), так таскаются непонятно зачем нужные конструкции из других языков и концепций. Писал человек явно не знакомый ни с PHP, ни с Perl, ни с UNIX-way. Многопоточность обеспечивает Web-сервер, так как нигде больше PHP не применяется (не прижился нигде больше). Неявное приведение типов - это концептуальная вещь. Это все-равно, что критиковать президента за обладание властью. Критиковать следует недостатки, которые будут устранены, например, тот же UNICODE, поддержка которого будет введена в PHP 6. Критиковать интерпретатор за интерпретируемость, а слабую типизацию за автоматическое приведение типов, ИМХО, наивно и глупо. Это никогда не будет исправлено, так как язык задумывался именно так. Постараюсь переработать раздел и добавить реальной критики (например, вопиющие ошибки, неисправляемые годами, несогласованный синтаксис функций и т.п.). --Cheops 11:13, 18 июля 2008 (UTC)

Для некоторых задач многопоточность в вебе нужна — например, агенту RSS выгоднее параллельно запрашивать RSS, а не последовательно. Почему убрали «Неявное приведение типов» — ведь есть проблемы, например в if (strpos("abc", "a")). Сборка мусора важна для программ, ведь у PHP есть GTK биндинги и работа из консоли. --A.I. 05:19, 19 июля 2008 (UTC)

Да, есть многопоточные задачи, и они решаются разными способами, специальным расширением или постановкой нескольких заданий в планировщике. Мне не нравится, что энциклопедическая статья преврщается в журнальный обзор. C++ тоже не поддерживает многопоточность на уровне синтаксиса - поддержка эта реализуется на уровне системных вызовов и API. Однако, его никто не критикует за отсутствие многопоточности, так как операционная система предоставляет соответствующие инструменты. А в языке многопоточности нет. Происходит смешивание задач операционной системы, исполняемой среды и самого языка. Потоки - это вообще не уровень прикладных языков программирования - это уровень операционной системы, ну может исполняемой среды. Обсуждение таких проблем допустимо при инженерном обзоре в тематическом журнале, но это же энциклопедическая статья - здесь должнать быть строгая ортогональность.

Проблем с проведением типов нет, язык предоставляет все возможности для работы с ними if (strpos("abc", "a") !== false). Нельзя напрямую копировать конструкции сильнотипизированного языка на слоботипизированный, даже если они оба C-подобные. Проблема не в приведении типов, а в слабом освещенности вопроса - вот это действительно следует отметить, документация до недавнего времени была действительно слабая - на PHP переходили с Perl и C++ и почти никто не озаботился более или менее подробным освещением особенностей синтаксиса. Только в последнее время ситуация выправляется.

«Сборка мусора важна для программ.» - Сборка мусора важна, когда программа не отдает память обратно системе, такие языки действительно имеются, например, Java не отдает операционной системе память, а отдает своей виртуальной машине, когда память заканчивается, включается сборщик мусора, который лишнюю память виртуальной машины отдает операционной системе. В C/C++ необходимо динамически выделенную память отдавать явным образом. Причем это приобретает значение, если процесс висит постоянно и долго, сервера написанные на C/C++ могут висеть в памяти долгие месяцы, как и виртуальная машина Java. PHP-процесс отрабатывает за доли секунды и отдает память сразу, отдает операционной системе. Не пишут на PHP приложений висящих долгие месяцы - он для этого слишком медленный. Более того, по умолчанию время выполнения скрипта ограничено 30 секундами. Язык специально создан для быстрых задач. Проблемы как таковой не стоит - упоминать это ради красного словца в энциклопедической статье считаю лишним. Помоему в правилах указывается - если стоят сомнения писать или нет - лучше не писать. Просто перегружаем статью явной ерундой - сборкой мусора (проблема с которой практически невозможно столкнуться при современном состоянии дел), пасхальными яйцами - буд-то это не весть что какой эксклюзив (любая шаровара ими напичкана, мама не горюй), субъективными сравнениями с Python и прочим. --Cheops 07:43, 19 июля 2008 (UTC)

> Вообще раздел критики ниже всякой критики

Критика приветствуется.

> мало того, что используется неочевидная функция range() вместо array(),

С помощью функции array() сложновато создать массив с числами от 1 до 100.

> так таскаются непонятно зачем нужные конструкции из других языков и концепций.

Я привел код для сравнения PHP vs. Python. На питоне аналогичные конструкции записываются более кратко, более читабельно, более переносимо (при переходе Non UNICODE <-> UNICODE).

> Писал человек явно не знакомый ни с PHP, ни с Perl, ни с UNIX-way.

Я долгое время программировал на PHP. Потом мне надоело боротся с его недостатками и я перешел на Python.

> Многопоточность обеспечивает Web-сервер, так как нигде больше PHP не применяется (не прижился нигде больше).

Почему-то PHP постоянно проталкивают как язык общего назначения: пишут библиотеки для GUI, работы с реестром, есть даже WEB-сервер целиком написанный на PHP [1]. Но без таких вещей как многопоточность и нормальное управление памятью язык не прижился в качестве удобного каждодневного инструмента (тот же Perl активное используется в Linux).

> Неявное приведение типов - это концептуальная вещь. Это все-равно, что критиковать

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

Я не против неявного привидения типов, мне интересны следующие почему: почему если к массиву применить конструкцию $A<<2, то получится 4, почему если к файл умножить на 2, то получится 4, почему 1024<<"$" равно 1024? Это нигде не документированно и совсем не очевидно (почему 4 а не 10, почему 1024 а не 2048?). Если в PHP есть "Неявное приведение типов", то почему нигде нет четких правил преобразования массива к числу или числа к массиву? Почему в коде:

$fin = fopen('some_file.txt', 'rb');
array_slice($fin, 3, 5);
print $fin[2];

функция array_slice выдает ошибку (не произошло конвертирование file->array) а функция count возвращает 1? Мне нужно было назвать раздел не "Неявное приведение типов", а "Неявное недокументированное неочевидное и неконтролируемое приведение типов". Это касается не всех случаев приведения типов, а лишь некоторых. В частности тех, что я приводил в примерах.

> Критиковать следует недостатки, которые будут устранены, например, тот же UNICODE, поддержка которого будет введена в PHP 6. Критиковать интерпретатор за интерпретируемость, а слабую типизацию за автоматическое приведение типов, ИМХО, наивно и глупо. Это никогда не будет исправлено, так как язык задумывался именно так.

Об этом стоит упомянуть, как о неприятных (в некоторых ситуациях, которые я описал в статье) особенностях языка.

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

Введение ООП в базовых типах языка исправило бы львиную долю проблем с несогласованным синтаксисом функций. Для этого я и приводил куски Python-кода.

Еще на мой взгляд стоит упомянуть о различных стилях условных операторов:

// вариант 1
if(condition) {code;}

// вариант 2
if(condition):
  code
endif;

Зачем два варианта? Это негативно сказывается на читабельности исходного кода, если в одном месте будет использоваться стиль с фигурными скобками, а в другом - двоеточие и endif;

> Отсуствие обратной совместимости между версиями языка

Обычно увеличение главной версии языка приводит к ломанию обратной совместимости. Это проблема не только PHP. Perl 5 лишь частично совместим с 4-ой версией. Python 3 не будет совместим со 2-ой версией.

В разделе критики нужно написать, что главный недостаток в том, что язык делали через ... одно место 8-]. Козырь 11:03, 21 июля 2008 (UTC)

>С помощью функции array() сложновато создать массив с числами от 1 до 100.

Да, разве это требуется для демонстрации отсутствия прямых индексов - два-три элемента в массиве хватило бы.

>Я привел код для сравнения PHP vs. Python. На питоне аналогичные конструкции

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

>Я долгое время программировал на PHP. Потом мне надоело боротся с его недостатками и я перешел на Python.

Совершенно не хотел оскорлять никого специально, но очень уж, как мне показалось, перевес большой в сторону Python, а не в сторону PHP.

>Почему-то PHP постоянно проталкивают как язык общего назначения

Однако, как человек, которому надоело бороться с недостатками вы прекрасно понимаете, что дорога ему в языки общего назначения заказана, мало того, что слишком на Web-ориентирован, так и ещё и глюков превеликое множество, с которыми никто не торопится бороться. Его можно использовать как язык общего назначения, но он не прижился в этой сфере и все его забросили. Сервер на PHP - это из разряда курьезов, ну кто в здравом уме будет использовать сверхмедленный сервер, когда быстрых полно.

>Если в PHP есть "Неявное приведение типов", то почему нигде нет четких правил преобразования массива к числу или числа к массиву?

Это глюк - массивы, конструкции из нескольких элементов не должны приводится ни к какому из типов кроме логического, т.е. либо 1, либо пустая строка, означающая FALSE. В противном случае должно выводится предупреждение, как в случае array_slice(). count() функция специальная - она все считает, что ей не подсунуть и в лишь в одном измерении. Это не самый страшный глюк, так как на него нарываются не часто, есть покруче - при наследовании если элемент имеет в имени символ подчеркивания _, он заменяется на i - так, что наследованием либо вообще пользоваться нельзя (а вы ещё базовые типы хотите в объекты превратить), либо очень осторожно и длится это безобразие с 5.0.0 и до сих пор не исправлено. Лучше выделить отдельный параграф, но не приводить в нем код, а просто словами описать - людей, не знакомых с синтаксисом, код будет отпугивать.

>Введение ООП в базовых типах языка исправило бы львиную долю проблем с несогласованным синтаксисом функций. Для этого я и приводил куски Python-кода.

Python задумывался как полностью объектно-ориентированный язык программирования вроде Smalltalk, PHP - задумывался как классический С-подобный язык, в котором базовые типы элементарны. Ещё больше можно было бы улучшить ситуацию, если бы все переменные не начинались с символа $, а имели разные символы как в Perl в зависимости от того, переменная это, ассоциативный или индексный массив. Но так мы получили бы ещё один Perl или ещё один Phyton. Языки разные и решают разные задачи и разрабатывают их разные люди с разным видением мира. PHP разрабатывали бывшие Perl-овцы и C-онисты, которые вообще говоря не очень-то объектно-ориентированный подход любят. Кроме того, объектно-ориентированный подход противоречит слабой типизации. Что такое класс - это по сути сильная типизация, два разных класса - это два разных типа. А PHP наоборот пытается типизацию размыть. Поэтому и на ООП в PHP и Perl все положили - концепция такая. Эта критика не очень уместна в статье по PHP - это действительно никогда не будет реализовано.

>Еще на мой взгляд стоит упомянуть о различных стилях условных операторов:

Вот это абсолютно точно и является прекрасным примером неортогональности, о которой я попытался написать в статье. Это пример как не следует разрабатывать промышленные языки. Если ничего не путаю, то в предложениях к PHP 6 предложили даже исключить вариант if(condition):, однако оно было отклонено. Неортогональность ещё гармонично в Perl смотрится, так как Perl создавался как контекстный неортогональный язык и у него концепция очень выверена, в PHP это все действительно ужасно и коряво реализовано - винегрет, а не язык. Единственное, что его спасает, очень удобный и очень воввремя появился.

>В разделе критики нужно написать, что главный недостаток в том, что язык делали через ... одно место 8-].

Вот это единодушно поддерживаю. Только слова покорректнее подобрать следует: Отсутствие продуманной концепции языка, повлекшей многочисленные версии и изменения базовых конструкций... Или что-то в этом духе. Cheops 21:45, 21 июля 2008 (UTC)

Почему №1: потому что не надо так писать - приведение числа к массиву и массива к числу документировано как неопределённое

Почему №2: по правилам приведения строки в число

"PHP задумывался как промышленный/с-подобный/... язык" - PHP вообще как язык программирования не задумывался

--Anton Khorev 22:24, 21 июля 2008 (UTC) upd --Anton Khorev 22:39, 21 июля 2008 (UTC)

---

Не понимаю, почему справедливое требование привести хоть один пример, когда код php некорректно работает в более поздней версии, вызывает войну правок. И я вообще бі не говорил, что обратначя совместимость ОТСУТСТВУЕТ. Лично я за семь лет не столкнулся ни с одной проблемой обратной совместимости.--Tmanager 11:52, 7 июня 2009 (UTC)

• Вероятно ООП возможностями не пользуетесь и PHP 3 не застали? Иначе не понятно, как вам это удалось... но даже если удалось, это не значит, что проблемы не существует. В PHP 6 опять будет финт ушами: ereg-функции будут вынесены даже не из ядра, а вообще из стандартных расширений. Это теперь обратной совместимостью называется? Про эпопею с register_globals и «длинными» массивами, которые, в PHP 6 будут исключены даже не упоминаю — притча во языцах.--Cheops 20:17, 7 июня 2009 (UTC)

Пасхальные яйца

Еще один код, работающий на PHP 5 - отображает картинку с иероглифами: любой_сценарий.php?=SUHO8567F54-D428-14d2-A769-00DA302A5F18

А вы точно ничего не напутали? Сдаётся мне, что это пасхальное яйцо Suhosin patch  (англ.) , а не PHP. Предлагаю либо убрать это пасхальное яйцо из статьи, либо чётко указать его происхождение, чтобы не вводить никого в заблуждение. Судья 04:38, 25 июля 2008 (UTC)

Общий пример

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

Основные требования:

• Ёмкий, но лаконичный.
• Максимально показан синтаксис языка.
• Иллюстрация основных достоинств.
• Раскрытие недостатков.
• Отображение решений самых повседневных задач (без чего ни один проект не обходится).
• Пример должен быть написан в хорошем общепринятом стиля программирования на PHP.
• Максимальная универсальность: должен работать на самых популярных платформах и с любыми настройками конфигурации.
• Плотная интеграция с текстом статьи. Внутренние ссылки должны быть из текста в пример и из примера в соответствующий текст.

Что стоит упомянуть:

• Получение основных сведений.
• Максимум функций со строками и массивами.
• Регулярки.
• Обработка входных данных пользователя. Как сделать так чтобы не хакнули. Кавычки, слэши и прочая шелуха.
• Работа с СУБД (возьмём MySQL).
• Работа с файлами и самой ФС.
• Особенности областей видимости (пространств имён).
• Работа с несколькими модулями. Кстати, можно сделать и "многомодульный" скрипт.
• Работа с разными типами данных (в том числе преобразование и определение типов).
• Предопределённые переменные (в т.ч. и суперглобальные).
• "Переменные" переменные $$my_var, "переменные" функции $myfunc(), лямбда-функции.
• Различные способы передачи параметров функциям.
• ООП. Наследование. Все "волшебные" методы.
• Работа с протоколом HTTP (анализ заголовков и их правильное формирование). Здесь достаточно тех, которые нужны для поисковиков.

Пример предлагаю писать по мере расширения статьи. Как только упомянули какую-то особенность, то сразу отобразили её в примере. Поэтому обязательно нужно сразу решить что скрипт будет делать. Желательно это должна быть какая-то реальная задача из повседневности или что-то очень полезное. Callidus 07:10, 25 сентября 2008 (UTC)

Такое ощущение, что создается не статья для энциклопедии, а справочная документация или книга. Помоему цель статьи создать представление об языке, а не описать его полностью. Последнее в рамках статьи просто не удобно - документ разбивать следует. Если требуется отразить более глубоко PHP в Википедии, вероятно, разумно продумать систему связанных статей, как это делается в других объемных областях. Регулярные выражения вероятно лучше описывать в статье, посвященной регулярным выражениям (тем более они заимствованы из Perl и UNIX, не разрабатывались создателями языка), взаимодействие с MySQL разумно описать в статье по MySQL, а от сюда сослаться. Про файловую систему лучше писать в соответствующей статье. Это энциклопедия, а не учебник. В ней должны быть энциклопедические знания, а не практические приемы и готовые программные рецепты. Cheops 09:32, 10 ноября 2008 (UTC)