Обсуждение:PHP

↓

Пожалуйста, добавляйте новые темы снизу

ООП в PHP

Объе́ктно-Ориенти́рованное Программи́рование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием, — прототипов).

ООП прославился из-за того, что помогал разработчикам добиться максимальной защиты и оптимизации кода. Классы очень удобны по своей натуре. Но слишком сложны для восприятия «с нуля», я советую учить ООП тем, у кого есть представления о программировании, и тем кто написал хотя бы парочку программ на Объектно не Ориентированном Программировании. ООП в PHP появился довольно недавно, начиная с 3-ей версии, там были только «упоминания» про объектно-ориентированность. В 4-ой версии ООП был значительно улучшен, но все же желал надеяться на лучшее… В 5-ой версии ООП представлялся уже полноценно разработанным для разработчиков. Это возникло из-за многочисленных критик в сторону разработчиков PHP.

Класс — это тип, описывающий устройство объектов. Понятие «класс» подразумевает некоторое поведение и способ представления. Понятие «объект» подразумевает нечто, что обладает определённым поведением и способом представления. Говорят, что объект — это экземпляр класса. Класс можно сравнить с чертежом, согласно которому создаются объекты. Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области.

Класс является описываемой на языке терминологии (пространства имён) исходного кода моделью ещё не существующей сущности, т. н. объекта.

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

Структура данных «класс», представляющая собой объектный тип данных, внешне похожа на типы данных процедурно-ориентированных языков, такие как структура в языке Си или запись в Паскале или QuickBasic. При этом элементы такой структуры (члены класса) могут сами быть не только данными, но и методами (то есть процедурами или функциями). Такое объединение называется инкапсуляцией. При всем притом «Методы» могут даже и не знать что кроме них в Объекте (Классе) есть что-то кроме него.

Основные понятия: 1) Всё является объектом. 2) Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия. 3) Каждый объект имеет независимую память, которая состоит из других объектов. 4) Каждый объект является представителем (экземпляром) класса, который выражает общие свойства объектов. 5) В классе задаётся поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия. 6) Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определённого класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве

--Иван Паламарчук 17:53, 27 июля 2010 (UTC)

Наконец-то кто-то понятно объяснил. Спасибо ДвотьПроцентов (обс.) 10:26, 15 мая 2021 (UTC)

Даты выхода версий PHP

Предлагаю добавить таблицу с датами выхода всех версий PHP, как в jQuery. 91.202.241.153 18:17, 21 января 2011 (UTC)

Слишком объемной таблица будет и сложно будет объективно отразить все изменения (а главное, причины) в таблице, а без описания нововведений в одних номерах информации мало. У jQuery еще поколения библиотеки не менялись, а в PHP таких смен произошло достаточно много, это и переход на PHP 3, потом на PHP 4, потом на PHP 5 и, наконец, ползучая революция в версии 5.x. Это как минимум нужно несколько таблиц (желательно под каждую версию) и лучше, если под это будет выделена отдельная статья (или организовать это в статье История PHP), итак объем статьи уже достаточно приличный - все же это не книга, а статья. А лучше вообще не связываться форматом таблицы, а разиваться статью История PHP.--Cheops 15:35, 1 марта 2011 (UTC))

Многопоточность

Убрал рассуждения про процессы и потоки, стремительно выливающиеся в новую статью. Все-таки не дело. Многие языки не имеют поддержки многопоточности, ну сказали и ладно, не надо писать трактат о параллельных вычислениях в статье, посвященной не поддерживающих их языку. Есть статьи посвященные многопоточности, параллельным вычислениям — вот там и надо это все писать. Тем более в ход пошли расширения, а они не все стандартные, я завтра напишу расширение, которое будет только под Windows работать и будет содержать обертки для соответствующих WinAPI-вызовов и что из-за этого можно будет утверждать, что язык поддерживает многопоточность? На уровне ядра нет поддержки и так почти во всех языках. В C тоже нет поддержки потоков — эту поддержку библиотеки обеспечивают, это не мешает создавать системы обеспечивающие эти самые потоки на C. Я вообще не понимаю, зачем ходить и в каждой статье писать, что PHP не поддерживает многопоточность, Pascal не поддерживает многопточность, ActionScript не поддерживает многопоточность… да это вообще не сфера языков, это сфера операционных систем и сред выполнения, это они поддерживают многопоточность (параллельность вычислений в рамках единого адресного пространства) и наличие процессов (параллельность с разделенными адресными пространствами).

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

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

Завтра кто-нибудь придет и напишет в разделе критики, о слабой поддержке 3d-вычислений, о неспособности кофеварения, о том, что платят мало за PHP-код и т. п. А так каждый раз смотрю и дивлюсь, а зачем бы мне понадобилась многопоточность, чтобы ответить на один единственный запрос клиента, с которым мы все-равно связаны жестким протоколом, ничего я ему не смогу послать в обход сервера? Да ладно бы PHP еще где-то использовался, он же нигде по сути больше не используется, кроме как в составе Web-серевера.--Cheops 16:45, 18 января 2012 (UTC)

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Рецензирование статьи PHP

Хочется довести статью до уровня хорошей. Хотелось бы увидеть все пожелания и замечания к статье. Статью я не писал, но о теме знаю многое и могу написать, надо лишь подсказать что. Заранее спасибо. --Distdev 14:20, 30 октября 2009 (UTC)

Значимость не раскрыта. Это же глобальная штука, основа большинства форумных и сайтовых движков. Partyzan XXI 20:40, 30 октября 2009 (UTC)

Сейчас внимательно прочитаю статью и напишу рецензию. Раньше статью почти не читал, т.к. хорошо знаю PHP.--Кae 12:41, 7 ноября 2009 (UTC) Вот:

Замечания от Kae

По имеющемуся содержанию:

1. О нововведениях в 6.0. Вряд ли следует считать нововведением удаление устаревшей функциональности. Может есть что-то действительно новое?
2. Раздел "Обращение к переменным и функциям" надо немного унифицировать. Создается впечатление, что в конце примера приведено некое исключение. На самом деле обычная "переменная переменная".
3. Ключевые слова, имена переменных и т.д. набраны полужирным шрифтом. Я думаю, что лучше форматировать подобные вещи так: public.
4. На мой взгляд, лучше в примерах использовать стиль отступов с операторной скобкой на отдельной строке. Так более читаемо.

Чего не хватает:

1. Два способа использования: в среде сервера и в CLI. Различия, особенности и т.д.
2. Что же делает PHP удобным для веб-программирования (какие специальные средства)? Да, сейчас написано про суперглобальные массивы, но надо более конкретно описать веб-специфичные фичи.
3. Фреймворки и для чего они нужны.
4. Про синтаксис можно подробнее написать. --Кae 15:49, 7 ноября 2009 (UTC)

Ответы

1. я думаю, информацию об удалении устаревшей функциональности должна быть. Поскольку это не просто какие-то редко используемые особенности, а то, что встречается в разработках повсеместно и то, о чем было много обсуждений и споров.
2. подправил немного.
3. Сделано. Имена суперглобальных массивов остались полужирными из-за оформления их как списка определений.
4. согласен, Сделано. Надеюсь, холиваров не будет (:

Про «чего не хватает» дополню попозже--Distdev 10:07, 9 ноября 2009 (UTC)

«чего не хватает»:

1. Сделано
2. что еще надо там описать, например?
3. что такое и для чего нужны фреймворки - это тема отдельной статьи
4. насчет синтаксиса тут терзают сомнения - это обширная тема, её вообще можно ынести в отдельную статью, как в en-wiki. Вопрос в том, насколько глубоко о нем рассказывать.

--Distdev 12:17, 11 ноября 2009 (UTC)

Структура статьи

Не совсем ясна общая композиция. Нет ощущения логики развития сюжета: какие-то особенности, какая-то критика, попытка дать обзор различных версий. Кое-что больше подходит для Wiki-учебника, а что-то вообще нераскрыто (на первый взгляд). Рассмотрим подробнее:

1. Раздел «Особенности» не нужен. К тому же тут сообщаются общие вещи, свойстсвенные нескольким языкам: какие уж тут особенности?
2. Нужен раздел «Описание», а внутри: «Синтаксис», «Типы данных», «Операции». Причём, при описании синтаксиса следует описывать сам синтаксис, а не взаимодействие кода PHP c HTML. Следует обязательно написать о том, что при применении «скриптовых» языков интерпретатор языка является генератором HTML-кода. Такое даже можно вынести в преамбулу в виде одного предложения: „язык PHP предназначен для генерации HTML-кода на стороне сервера“ (что и отличает его от JavaScript). „Программа PHP может быть оформлена в виде вставок в HTML-код, а может выглядеть как обычная программа.“ Например.
3. Нужно описание архитектуры языка. В этом смысле важно то, какие имеются типы данных, для решения каких задач они обычно применяются, какие реализованы стандартные библиотеки. Отдельный разговор про среды разработки.

В общем, писать надо так, чтобы было понятно, что из чего берётся и для чего приводится. Если потребуется, могу и сам принять посильное участие в работе над статьёй. --OZH 18:22, 18 ноября 2009 (UTC)

Ответы

1. Не согласен. Не все языки обладают данными особенностями, поэтому данный раздел должен быть. См. например, Java#Основные особенности языка
2. Разделение, возможно, стоит немного подправить, но не сильно. См. хорошую статью Python
3. Типы данных уже описаны - их 8. Стандартная библиотека у PHP одна, и вопрос о целесообразности ее описания — внужна ли она тут, она не так часто используется. Про среды разработки однозначно хватит того, что сейчас есть (в виде таблицы), возможно, что-то оттуда выкинуть, а что-то добавить.

--Distdev 19:17, 18 ноября 2009 (UTC)

Нет единой концепции

Статья, конечно, караул — несколько лет её мурыжим. К сожалению, язык программирования очень популярен и время от времени набегает огромное количество людей с мелкими правками (собственно, что греха таить, сам такой), вместо того, чтобы её полностью переписать. В результате большую часть времени статья представляет сборную солянку с разными стилями и задачами (со стилем я ещё борюсь, а на структуру давно рукой махнул). Нет единой концепции, никогда «Пасхальные яйца» не будут согласовываться с «Объектно ориентированными-возможностями». А по уровню заголовков, получается, что «Пасхальные яйца» — это основная особенность языка, привлекающая разработчиков и это одна из основных задач, которыми они занимаются. Смешно. И будет оставаться смешным, так как «Пасхальные яйца» — это шутка, забава, выпендреж (в зависимости от вкуса).

1. Предложение: раздел «Пасхальные яйца» просто удалить — не место этому в серьезной статье, да и на функциональности языка это никак не отражается. У читателя это вызывает диссонанс с предыдущим материалом и не понимание: зачем это здесь?
2. Кроме того, «Особенности» и «Использование» здорово перекликаются между собой — попытался их немного разделить, но все равно до конца не получилось. Кроме того, «Популярные приложения» — это ведь тоже использование, а находятся в другом разделе. В общем структура статьи хромает. Я бы кстати, «Особенности» тоже в «Архитектура языка» переименовал бы. «Особенности» — это слишком многозначно (особенности чего? Архитектуры, применения, метода разработки, инструментов?) и здорово перекликается с «Использование».
3. История языка. Если быть честным, язык находится в стадии глубокой стагнации, нет годичной-двухгодичной смены версий. Т.е. уже можно говорить просто о PHP (как о C++ или Perl), не акцептируя внимание на версии? Предлагаю под историю создать отдельную статью, на которую сослаться из основной — повторов в статье будет меньше. А ценной информацией из статьи по истории можно будет усилить оставшиеся разделы.

--Cheops 11:32, 28 ноября 2009 (UTC)

Ответы

Насчёт «пасхальных яиц» - посмотрите хорошую статью Mozilla Firefox, там они довольно неплохо лежат вровень с другими разделами. Собственно у меня нет однозначного мнения касательно данного раздела - с одной стороны как бы не в тему, но с другой - в других статьях данный раздел присутствует, почему бы и нет? Насчет популярных приложений, особенностей, архитектуры и использования - мне кажется следует их перераспределить примерно в следующем виде:

1. Особенности (или архитектура) - сюда пойдёт то, что сейчас в особенностях + php_mod, php_cgi, ... из использования.
2. Популярность - сюда перенести данные о популярности и крупных сайтах из использования + сюда же популярные приложения. Непонятно только куда поместить фреймворки и сам раздел (Популярность) - то ли в начало, то ли в конец.

Насчёт истории, наверное, пока все же не соглашусь. Стоит отметить хотя бы недавнюю версию 5.3, которая принесла довольно значительные изменения/нововведения. --Distdev 11:52, 28 ноября 2009 (UTC)

Дело в том, что Mozilla Firefox это ведь программа, а текущая статья посвящена не сколько PHP как исполняемому модулю, сколько PHP, как языку программированию. Ведь нет же никаких пасхальных яиц в C++ и быть не может, так как реализаций компилятора очень много. Да в PHP это не так, возможно пока не так, в любом случае в качестве заголовка второго уровня «Пасхальные яйца» в языке программировании не совсем корректно (это же не особенность языка, это особенность реализации). Вот его бы был раздел второго уровня «Реализации», тогда да, вот де есть официальная сборка (собственно единственная), там есть такая фича. Т.е. происходит нарушение стиля, мы постоянно описываем, то язык программирования, то исполняемый модуль PHP.

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

В разделе истории можно оставить один абзац, который откуда пошел язык и современное состояние дел, а в основной статье все остальное. Вообще говоря объем статьи уже значительный, а большая часть материала в разделе «История» представляет специальный интерес и вряд ли заинтересует рядового читателя, не знакомого глубоко с языком. Собственно об этих особенностях PHP 5.3 не с руки писать в основной статье — калибр не тот, а в статье, посвященной истории - любая новая особенность, да пусть даже и дополнительный параметр одной из 1000 функций смотрелись бы уместными. -Cheops 12:14, 28 ноября 2009 (UTC)

Наверное историю действительно стоит пока оставить, добавил абзац в «Особенности» почему версия языка программирования в PHP получила такое значение, которое у других языков практически не наблюдалось (или не наблюдалось до не давнего времени).--Cheops 12:48, 28 ноября 2009 (UTC)

---

— Раздел «Литература» для чего и для чего он такой, какой есть? Википедия это не инструкция и изучать по ней непосредственно программирование на языке — не та возможность, которую авторы (статьи Википедии 213.171.63.227 08:41, 24 февраля 2010 (UTC)) должны стремиться обеспечить. Кроме того, единообразие авторов (В списке литературы 213.171.63.227 08:41, 24 февраля 2010 (UTC)) наводит на размышления, что добавлены эти ссылки были в чьих-то небескорыстных интересах.
— Инвентаризация довлеет над энциклопедическими сверхидеями. Статья рыхла и неинформативна. Нет переходов от общего к частному и от простого к сложному. Зато много списков, которые не помогают почёрпывать из статьи знания.
PHP это язык программирования. Незнакомому с темой интереснее всего было бы следующее, насколько мне кажется: зачем и почему он возник к тем, что уже и так есть, и почему он не единственный остался до сих пор. Вот в те стороны даже поползновений в тексте статьи почти не видно. В английской Википедии есть, кстати, раздел по безопасности.
В то же время неструктурированное упоминание элементов синтаксиса зачем-то. Что они дают, эти поминания непосредственных операторов? Для чего они в энциклопедической статье, не являющейся инструкцией? И почему упомянуты эти конкретные, а не вообще все? Может быть, у авторов статьи были действительные разумные основания для включения того, что включено. Но не хватает предваряющих обобщений и понятных не только программистам прямо высказанных пояснений.
— Раздел «Интегрированные среды разработки для PHP» без слов не понятен. Что это такое, кто все эти люди? Полный ли список? Актуальный ли? Нужны ли перечисленные вещи вообще для разработчиков? Если нужны, то какие лучше и какие хуже?
— Вычитанности нет, проблемы с пунктуацией. Находятся слова «Справедливости ради надо отметить» неуместные в научном энциклопедическом стиле. Сноска 29 гласит «Проект находится в экспериментальной стадии». Пример убойного русского языка.
— Сноски не оформлены {{cite web}}.
— Раздел «Рынок труда» в текущем виде не содержит энциклопедически ценной информации и подаётся некорректно.
Вердикт: мне не нравится −_− Легат Ская 14:54, 23 февраля 2010 (UTC)

Закрыто. >_< Легат Ская 16:08, 8 марта 2010 (UTC)

Joomla и Drupal - фреймворки?

Почему внизу страницы, там где раздел Категории "PHP", в категории "Фреймворки" находятся Joomla и Drupal? Разве это фреймворки? У них в статьях прямым текстом указано:

"Drupal (друпал) — система управления содержимым (CMS), написанная на языке PHP и..."

"Joomla! — система управления содержимым (CMS), написанная на языках PHP и JavaScript, ..."

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

Недостатки

Очень мало недостатков PHP перечислено, основные не затронуты вообще. Например, PHP как сам медленный (в силу того что он не компилируется, а интерпретируется, что приводит к разбору кода прямо при выполнении скрипта, к тому же компилятор мог бы оптимизировать код), так и разработка на нём высокими скоростями и качеством не отличается (в основном потому, что нет типов данных, что приводит к трудноуловимым ошибкам). Также статья нуждается в подразделе типа "Назначение", в котором следует указать, что PHP хорош для простых сайтов-визиток и не особо рентабелен для серьезных проектов (см. мое замечание о скорости разработки и трудноуловимых ошибках 84.237.53.14 00:39, 6 декабря 2012 (UTC)).

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

Слабая типизация - это особенность языка, более того в последних версиях, имеется возможность её усиливать, явно указывая тип при передачи аргументов функциям и классам. Нельзя слабо-типизированному языку ставить в вину слабую типизацию, а сильно-типизированному языку - сильную типизацию. Это особенность языка, не она причина низкого качества кода (и без неё довольно недостатков, одна полуреализованная объектно-ориентированная модель чего только стоит). Лимон будем ругать за то что кислый, а малину за то что сладкая? Лучше сосредоточиться на описании особенностей. --Cheops 05:03, 24 марта 2013 (UTC)

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

Вы путаете строгую и статическую типизацию. - Anon

Ну что, давайте-ка я вброшу. рнр: фрактал плохого дизайна - Anon

• Спасибо. Очень полезная статья переведена. Как-бы её в текс статьи интегрировать?.. Кстати, есть неплохая ответная: PHP — отстой! Но я люблю его! --Nashev 15:13, 14 октября 2013 (UTC)

• И как обычно, коментов на 50 экранов. Вброс удался. - Anon

Ссылки на другие языковые разделы в статье

Куда делись? 37.25.116.228 13:31, 1 октября 2013 (UTC)

Типизация

Типизация же слабая динамическая? Можно узнать, почему стоит только динамическая?

Устаревшая информация в разделе «Критика»

Также для версии 5.3 на данный момент отсутствует программное обеспечение Zend Optimizer. Однако разработчики планировали выпустить его в 2010 году

Да, но начиная с версии 5.5 PHP поставляется вместе с расширением Zend OPcache (доступным кстати и для некоторых более ранних версий, включая 5.3).

Следующее предложение тоже устарело (PHP 5.5 вышел в июне 2013 года):

7 марта 2013 года Zend Technologies объявили, что в версию PHP 5.5, когда она будет выпущена, решено интегрировать Zend Optimizer+, который включает в себя кэш опкодов и оптимизатор кода. Возможно, из-за этого выпуск версии затянется на 1-2 месяца

-- Bitobor 11:32, 13 ноября 2014 (UTC)

Перевод названия PHP/FI

Personal Home Page / Forms Interpreter (текущий перевод: «Личная Домашняя Страница / Интерпретатор форм») еще можно перевести как «Интерпретатор Домашней Страницы / Форм», и, мне кажется, этот перевод будет более точным. Пока изменил на мой перевод, кому не нравится, откачивайте. 209.58.128.137 06:45, 12 января 2015 (UTC)

• Но первоисточник [1] (цитирую: «In September of that year, Rasmus expanded upon PHP and — for a short time — actually dropped the PHP name. Now referring to the tools as FI (short for „Forms Interpreter“, „ combining the names of past releases, Rasmus introduced PHP/FI“)») говорит о том, что FI — «forms interpeter» - самостоятельное имя, то есть, имеем (PHP)/(FI), а не PH(P/F)I. Так что правильнее будет вернуть. РоманСузи 17:38, 22 января 2015 (UTC) И в АИ [2] тоже не так, так что возвращаю. РоманСузи 17:40, 22 января 2015 (UTC)

Фреймворки и cms

Предлагаю разделить этот раздел на 2, сослаться на определение каждого раздела, что такое фреймворк и что такое cms, объяснить их роль в php и уже потом список популярных, то что сейчас в куче написано не очень читабельно. 3dmaksik 21:21, 20 декабря 2015 (UTC)

@3dmaksik: Лучше перевести 2 соответствующих предложения из en:PHP#Use --Сунприат 09:32, 21 декабря 2015 (UTC)

Востребованность на рынке

Данный раздел сильно устарел. Информация ссылается на статью 2009 года. --Bolgarhistory (обс.) 01:06, 16 марта 2017 (UTC)

Как правильно читается по-русски?

C читается "си", USB - "юэсби"... А как читается php? 94.232.111.255 15:37, 26 ноября 2017 (UTC)

Правильно — «пи-эйч-пи». Но многие читают «пэ-ха-пэ». — Monedula (обс.) 18:19, 26 ноября 2017 (UTC)

А некоторые читают «пэ-аш-пэ». --Vasmedv (обс.) 08:23, 11 февраля 2019 (UTC)

О качестве кода

Уважаемые участники! Дополнительно хочу аргументировать свою правку: [3]. На любом языке без фундаментальных знаний основ программирования можно написать плохой код. Простота или сложность языка никак не влияет на качество. В купе с тем, что АИ на данное высказывание отсутствует, полагаю, что инфа почерпана из форумов, поэтому удалил. А уж про "сложности" настройки среды я вообще молчу - у того же C# вообще установка IDE на Windows все сама делает. --Bolgarhistory (обс.) 09:58, 12 декабря 2017 (UTC)

Класс языка

В карточке языка в классе языка на "императивный язык программирования" нет ссылки. Хотел добавить ссылку на https://ru.wikipedia.org/wiki/Императивное_программирование, но в коде не нашел, где это можно сделать. --Vasmedv (обс.) 08:23, 11 февраля 2019 (UTC)

Частное мнение неизвестного блогера как АИ по критике

Есть сомнения, что данный материал в статье соответствует требованиям ВП:ЭКСПЕРТ. Автор - аноним с неизвестной компетентностью в предметной области. --Bolgarhistory (обс.) 03:12, 19 января 2021 (UTC)

По поводу синтаксиса

SerafimArts, вот Вам код, скопированный в IDE. Никаких синтаксических ошибок без точки с запятой не наблюдается. Код запускается без ошибок. --Bolgarhistory (обс.) 12:31, 7 августа 2021 (UTC)

Кроме того, обращаю Ваше внимание на то, что анонимное объявление функции в принципе не влечёт за собой требования точки запятой. Точка с запятой нужна только при присваивании функции в переменную. --Bolgarhistory (обс.) 12:35, 7 августа 2021 (UTC)

Что значит "запускается без ошибок"? Вы хотя бы удосужились это сделать?

http://sandbox.onlinephpfunctions.com/code/ca080dc6131eb0a5561cefd0724b59712e94cd06

> Parse error: syntax error, unexpected token "fn" in [...][...] on line 11

Пожалуйста, ознакомьтесь с документацией по языку (пример номер #2): https://www.php.net/manual/ru/functions.anonymous.php SerafimArts (обс.) 12:55, 7 августа 2021 (UTC)

Я хочу извиниться за возможную резкость в высказываниях выше, однако просьба всё же действительно запустить тот код и самостоятельно убедиться в ошибочности Вашего мнения. SerafimArts (обс.) 12:58, 7 августа 2021 (UTC)

Если Вас смущает источник, то вот альтернативный в виде 3v4l: https://3v4l.org/UIV0i

Результат выполнения кода без точки с запятой возвращает синтаксическую ошибку. На всякий случай я сделал для Вас скриншот результата SerafimArts (обс.) 13:14, 7 августа 2021 (UTC)

Коллега, есть сомнения, что частный веб-сайт можно считать за АИ в данном вопросе. Я запустил скрипт на реальном интерпретаторе. IDE PhpStorm не демонстрирует ошибок синтаксиса. Полагаю, что вопрос можно решить только реальными практическими примерами, а не эмулятором с неизвестной начинкой. --Bolgarhistory (обс.) 14:35, 7 августа 2021 (UTC)

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

С другой стороны, если вас подобные аргументы не убеждают, то тогда предлагаю взглянуть на реализацию. Думаю исходный код самого языка является АИ для разрешения данного недопонимания:

1) Вот грамматика анонимных функций (обе) - правило inline_function: https://github.com/php/php-src/blob/6780aaa53266a19c4d0116329c163a8fe65b5413/Zend/zend_language_parser.y#L1203

2) Каждая из анонимных функций является выражением - правило expr: https://github.com/php/php-src/blob/6780aaa53266a19c4d0116329c163a8fe65b5413/Zend/zend_language_parser.y#L1194-L1198

3) Каждое выражение является частью правила операторов (statement), и обязано заканчиваться точкой с запятой: https://github.com/php/php-src/blob/6780aaa53266a19c4d0116329c163a8fe65b5413/Zend/zend_language_parser.y#L514

4) Далее, если вы пойдёте разворачивать грамматику, то получите информацию о том, что statement является частью top_statement, а сам файл состоит из списка этих top_statement.

В результате получаем: start -> top_statement_list -> top_statement -> statement -> expr + ";" -> inline_function. Т.е. каждое выражение в PHP (вот тут можете взглянуть на то, какие выражения есть в языке: https://github.com/php/php-src/blob/6780aaa53266a19c4d0116329c163a8fe65b5413/Zend/zend_language_parser.y#L1076), в том числе и statment-like (match, fn, anonymous function + class) обязаны грамматически завершаться точкой с запятой.

Думаю тот факт, что даже в исходном коде оригинального интерпретатора прописаны правила, подтверждающие мои слова, смогут Вас убедить? SerafimArts (обс.) 15:34, 7 августа 2021 (UTC)

Удалось повторить ошибку. Поэтому приношу извинения. Вы оказались правы! --Bolgarhistory (обс.) 16:28, 7 августа 2021 (UTC)

Ничего страшного. Я рад что удалось решить данный вопрос в диалоге. SerafimArts (обс.) 17:03, 7 августа 2021 (UTC)

Обсуждение раздела, связанного с GUI

Предлагаю раздел с "дополнительными возможностями", включающими GUI переместить в самый низ, сразу после "альтернативных реализаций". Считаю, что история языка, особенности работы и синтаксис важнее, нежели довольно обширный раздел с тем, чем пользуются, образно, "полторы калеки" в мире. SerafimArts (обс.) 13:47, 7 августа 2021 (UTC)

Отсутствие обратной совместимости как недостаток

Коллеги, в разделе "Критика" отсутствие обратной совместимости описывается как недостаток языка программирования. Однако такая совместимость между версиями в принципе невозможна. Нет ни одной технологии, которая сохраняла бы совместимость с устаревшими версиями. Кроме того, данная информация не подкреплена АИ: приведённый источник просто описывает несовместимость старых и новых версий, но не описывает это как недостаток. По итогу имеем ситуацию, что информация ОРИССная. --Bolgarhistory (обс.) 15:02, 17 августа 2021 (UTC)

За всю 30ти-летнюю историю HTML я припомню только удаление поддержки тега marquee. В этом случае, как бы это не прозвучало, но если сравнивать PHP с HTML, то у первого явные проблемы с сохранением BC. Десятки, если не сотни поломок между PHP3 (FI - вообще другой язык, так что его не учитываем) и PHP8 против одной единственной - работает не в пользу PHP.

С другой стороны, наличие обратной совместимости в PHP не уступает другим конкурентным технологиям, а все "депрекейшены" связаны с функционалом, который не используется (в большинстве случаев при принятии спорного решения может использоваться статистика, основанная на выборках среди всех публичных репозиториев с кодом), является не безопасным (например, удаление поддержки register globals) или приводит к разнообразным ошибкам (magic quotes, mbstring overload или из более актуального - неявное преобразование float в int с потерей точности).

Таким образом, при соблюдении, довольно очевидных "правил хорошего тона" при написании кода (хоть это и довольно размытое и субъективное понятие) - можно ни разу за всю свою практику не столкнуться с проблемами поломок BC: Например Yii, выпущенный в далёком 2008ом году под PHP 5.1 даже сейчас спокойно работает на PHP 8.0, а это, между прочим - разница в 11 "мажорных" (учитывая специфику версионирования PHP) версий языка.

Поэтому, считаю, что коллега прав и поломки BC нельзя однозначно трактовать как недостатки. Они есть, это факт, как и в любом другом ПО. Однако это типичный эволюционный путь, который не содержит никаких радикальных изменений (против, например, Python 2 -> 3, Perl -> Raku, etc). SerafimArts (обс.) 19:36, 18 августа 2021 (UTC)