Комментарии 121
охренеть, простите.
Ничего. Я думаю все… огорчились.
А чего там охеревать?
PDO и mysqli уже давно используются де-факто, потому что ещё со времён 4.1 в mysql библиотеку не вносили никаких обновлений в плане функционала, сконцентрировавшись на mysqli и PDO.
Так что ход очень даже логичный. А старые проекты частенько всёравно без допиливания рашпилем нормально не будут работать в любом случае. Качественный скачок в разработке на PHP случился относительно недавно и не многие фреймворки до сих пор способны работать в режиме E_ALL | E_STRICT.
Упоротые в любом случае наткнутся что mysql библиотеку в один день уберут из PHP даже если их предупреждать за 10 лет — потому что они упёртые бараны, либо компания жмотится и пока жаренный петух не клюнет — не даст обновлять. А скорее просто лет 10 ещё будут сидеть на старых версиях языка :)
PDO и mysqli уже давно используются де-факто, потому что ещё со времён 4.1 в mysql библиотеку не вносили никаких обновлений в плане функционала, сконцентрировавшись на mysqli и PDO.
Так что ход очень даже логичный. А старые проекты частенько всёравно без допиливания рашпилем нормально не будут работать в любом случае. Качественный скачок в разработке на PHP случился относительно недавно и не многие фреймворки до сих пор способны работать в режиме E_ALL | E_STRICT.
Упоротые в любом случае наткнутся что mysql библиотеку в один день уберут из PHP даже если их предупреждать за 10 лет — потому что они упёртые бараны, либо компания жмотится и пока жаренный петух не клюнет — не даст обновлять. А скорее просто лет 10 ещё будут сидеть на старых версиях языка :)
Между прочим, в официальных доках в разделе про mysql уже давно написано «If you are using MySQL versions 4.1.3 or later it is strongly recommended that you use the mysqli extension instead». Но соглашусь, новость немнго неожиданная :)
Эти заметки почему-то редко попадаются на глаза, до того как возникнет проблема.
Все верное. Давно пора почистить ядро от всяких там залетных.
Отличная новость же, это php еще чистить и чистить!
это только предложение или так уже факт будет?
Кто там говорил, что использовать фрейворки — зло? )
Точно не я (хоть я и был неоднократно минусуем за использование собственного фреймворка). Хотелось бы теперь на этих людей посмотреть.
Ещё не факт, что выбранный фреймворк обновят. Особенно если он не входит в пару-тройку самых распространённых.
Если разработчики не обновят — то извинете — к чёрту такой фреймворк :)
А зачем обновлять что-то? Хороший фреймворк должен позволить буквально одной-двумя правками в конфиге перескочить с MySQL на PDO/MySQLi
Кто мешает в своём классе для работы с СУБД пройтись replace'ом, заменив mysql_ на mysqli_ :)?
Ну это как-то несерьезно, кто с replace'ом дружен — тому и класс не нужен, общий интерфейс и несколько реализаций под mysql/mysqli/pdo — это мне понятно, а когда один класс в котором что-то правят replace'ом — был-ли в нем смысл вообще?
например то, что php.net/mysql_real_escape_string и php.net/mysqli_real_escape_string принимают разные параметры.
что типично для данного языка…
что типично для данного языка…
Пол интернета умрет, особенно если хостинги принудительно поставят PHP6. Да и одного deprecated достаточно — у половины сайтов включен вывод таких ошибок.
Хостинги обычно довольно консервативны и, в большинстве случаев, думают, что делают, так что вам не стоит переживать за смерть интернета. Тем более, что PHP6 ещё даже не близок к выходу.
Ой, когда все хостинги переползут на 5.3 — релизнется 5.6-6.х.
Это я к тому, что мейнстрим в основном подхватывается нестабильностью.
Это я к тому, что мейнстрим в основном подхватывается нестабильностью.
Это все конечно хорошо, но не для тех, кому переносить 100500 баз на новые реалии :)
НЛО прилетело и опубликовало эту надпись здесь
Самая популярная связка в написании веб приложений новичков, и тут такое…
Зато хотя бы аббревиатуру LAMP переименовывать не придётся.
Если сворачивают MySQL, то пускай и PostgreSQL свернут!
Чтобы никому обидно не было :)
Чтобы никому обидно не было :)
Это ещё зачем?
> Это ещё зачем?
Лето, солнышко. Два хомячка сидят на берегу реки и вяжут шапочки.
Сзади бегемот подходит:
— Эй, ребята, как тут глубина, нормально?
— Да, глубоко.
Бегемот разбегается и ныряет… а там воды по щиколотку, дно — железобетон, штыри торчат.
Хомячки дальше вяжут. Один другого спрашивает:
— Ты зачем его обманул?
Второй отвечает:
— А ты зачем вчера мою шапочку распустил?
Лето, солнышко. Два хомячка сидят на берегу реки и вяжут шапочки.
Сзади бегемот подходит:
— Эй, ребята, как тут глубина, нормально?
— Да, глубоко.
Бегемот разбегается и ныряет… а там воды по щиколотку, дно — железобетон, штыри торчат.
Хомячки дальше вяжут. Один другого спрашивает:
— Ты зачем его обманул?
Второй отвечает:
— А ты зачем вчера мою шапочку распустил?
Как желто >:(
Разработка php_mysql остановилась на поддержке функционала MySQL 4.1.3. Это расширение не поддерживает транзакции, объектный интерфейс, подвержено уязвимостям при подстановке значений в запрос. УРА, что его таки отключают, ведь остаются такие классные штуки как PDO и mysqli.
Разработка php_mysql остановилась на поддержке функционала MySQL 4.1.3. Это расширение не поддерживает транзакции, объектный интерфейс, подвержено уязвимостям при подстановке значений в запрос. УРА, что его таки отключают, ведь остаются такие классные штуки как PDO и mysqli.
Поддерживает всю функциональность MySQL 4.1+:
Расширение mysql: Нет
PDO: Большую часть
Поржал
Расширение mysql: Нет
PDO: Большую часть
Поржал
Угу, бардак с поддержкой MySQL сводит на нет все рассуждения о том, что РНР — хороший язык.
Бардак в обсуждении какого-либо гема сводит на нет все рассуждения о том, что Ruby — хороший язык?
gem не является поставляемой по умолчанию фичей, а три стандартных (!) способа подключения к MySQL с разным набором поддерживаемых фич — это звиздец.
НЛО прилетело и опубликовало эту надпись здесь
Три несовместимых друг с другом способа связаться с MySQL, каждый из которых не имеет полного набра фич, в стандартной поставке — это обширные возможности и свобода?
:))))))))))))))))
:))))))))))))))))
НЛО прилетело и опубликовало эту надпись здесь
Я не передергиваю, и предмет знаю (10 лет работы с этим убожеством). Буквально двумя сообщениями выше приведена таблица, описывающая весь этот звездец.
В частности, «фичи» типа: mysqli дает бОльше возможностей, чем PDO, но в нем нет named parameters. В PDO есть, но увы «PDO поддерживает большую часть функциональности MySQL 4+» мне не подходит.
Вот и сиди, крути велосипеды, что там, что там.
Нет, если борьба с отсутствием такого понятия, как «внятная, продуманная архитектура языка и понимание того, как его развивать» для вас — это обширные возможности и свобода, то я даже не знаю, что сказать…
В частности, «фичи» типа: mysqli дает бОльше возможностей, чем PDO, но в нем нет named parameters. В PDO есть, но увы «PDO поддерживает большую часть функциональности MySQL 4+» мне не подходит.
Вот и сиди, крути велосипеды, что там, что там.
Нет, если борьба с отсутствием такого понятия, как «внятная, продуманная архитектура языка и понимание того, как его развивать» для вас — это обширные возможности и свобода, то я даже не знаю, что сказать…
НЛО прилетело и опубликовало эту надпись здесь
> Ой, да ладно… Да, нигде никто не упоминал о питоне и руби. Оно всегда как-то само собой подразумевается.
Телепаты отправляются в пеший поход в сад.
> Знаете, как называется то, что вы делаете? Вот это вот — про документацию и понимание, как развивать… это популизм. Ни примеров, ни обоснованной точки зрения — ничего. Только одна ругань.
Вообще-то, это — обоснованное мнение, да еще и ссылкой подкрепленное :-\ Если вам мешают это увидеть шоры на глазах, пора избавляться от шор.
> А я вот положу на другую чашу весов:— реальное развитие языка, кто не верит — зайдите в репозиторий
Количество коммитов в репозиторий ничего не говорит о развитии. Язык развивается хаотично. У языка нет даже малейшего подобия такого понятия, как план развития. Это приводит к тому, что между минорными версиями может легко вноситься изменений, чем между мажорными — а это идиотизм.
Четкое понимание, что именно нужно языку отсутсвует, как класс, как у разработчиков (Zend), так и у большинства коммитеров.
> да… пересмотр многих архитектурных ляпов, таких как, например, php_mysql
Правильно, со вносом любого произвольного числа других архитектурных ляпов. Например, нахрена, анчиная с версии 5.0 (см. таблицу выше) с PHP в стандартной поставке идут еще две библиотеки подключения к MySQL, которые несовместимы между собой, и каждая их гкоторых не имеет полного набора фич?
> введение новых фишек (см. 5.4 патчноты)
См. выше про хаос в развитии. 5.4 идет тем же путем — в язык пачками (без какой-либо системности) добавляются кардинально меняющие его возможности. Причем сами же разработчики, по большому счету, кладут большой и толстый болт на собственные же рекомендации: wiki.php.net/rfc/releaseprocess (см. про experimental features и проч.)
> А вы надейтесь найти язык программирования, который будет делать все за вас.
Еще раз повторю: Телепаты отправляются в пеший поход в сад.
Качество языка в первую очередь влияет на то, что с помощью этого языка можно сделать. В хаосе сделать ничего нельзя. Нет, можно прикрывать глаза на отсутствие какого-либо понимания того, куда язык движется (при переходе 5.2->5.4 добавляется уже на порядок больше вещей, чем при планируемом переходе 5.x->6.x) и радоваться к растущим, как грибы после дождя, фичам из «взрослых» языков, но менее хаосом и убожеством от этого PHP не становится.
> Единственным интересным и достойным внимания средством разработки, конкурентом PHP я вижу только серверный JS. Но он еще незрел и слишком молод.
Телепаты отправляются в пеший поход в сад.
> Знаете, как называется то, что вы делаете? Вот это вот — про документацию и понимание, как развивать… это популизм. Ни примеров, ни обоснованной точки зрения — ничего. Только одна ругань.
Вообще-то, это — обоснованное мнение, да еще и ссылкой подкрепленное :-\ Если вам мешают это увидеть шоры на глазах, пора избавляться от шор.
> А я вот положу на другую чашу весов:— реальное развитие языка, кто не верит — зайдите в репозиторий
Количество коммитов в репозиторий ничего не говорит о развитии. Язык развивается хаотично. У языка нет даже малейшего подобия такого понятия, как план развития. Это приводит к тому, что между минорными версиями может легко вноситься изменений, чем между мажорными — а это идиотизм.
Четкое понимание, что именно нужно языку отсутсвует, как класс, как у разработчиков (Zend), так и у большинства коммитеров.
> да… пересмотр многих архитектурных ляпов, таких как, например, php_mysql
Правильно, со вносом любого произвольного числа других архитектурных ляпов. Например, нахрена, анчиная с версии 5.0 (см. таблицу выше) с PHP в стандартной поставке идут еще две библиотеки подключения к MySQL, которые несовместимы между собой, и каждая их гкоторых не имеет полного набора фич?
> введение новых фишек (см. 5.4 патчноты)
См. выше про хаос в развитии. 5.4 идет тем же путем — в язык пачками (без какой-либо системности) добавляются кардинально меняющие его возможности. Причем сами же разработчики, по большому счету, кладут большой и толстый болт на собственные же рекомендации: wiki.php.net/rfc/releaseprocess (см. про experimental features и проч.)
> А вы надейтесь найти язык программирования, который будет делать все за вас.
Еще раз повторю: Телепаты отправляются в пеший поход в сад.
Качество языка в первую очередь влияет на то, что с помощью этого языка можно сделать. В хаосе сделать ничего нельзя. Нет, можно прикрывать глаза на отсутствие какого-либо понимания того, куда язык движется (при переходе 5.2->5.4 добавляется уже на порядок больше вещей, чем при планируемом переходе 5.x->6.x) и радоваться к растущим, как грибы после дождя, фичам из «взрослых» языков, но менее хаосом и убожеством от этого PHP не становится.
> Единственным интересным и достойным внимания средством разработки, конкурентом PHP я вижу только серверный JS. Но он еще незрел и слишком молод.
> Единственным интересным и достойным внимания средством разработки, конкурентом PHP я вижу только серверный JS. Но он еще незрел и слишком молод.
Спасибо, посмеялся. Сразу видно человека, который только фреймворки и знает.
Спасибо, посмеялся. Сразу видно человека, который только фреймворки и знает.
НЛО прилетело и опубликовало эту надпись здесь
> Я ни слова не сказал про подсчет количества коммитов. Я говорил «посчитайте, сколько там коммитов»? Я сказал «посмотрите в репозиторий». Так что не будем.
Хорошо. Что именно я должен увидеть в репозитории? Восстанавливаю контекст: «А я вот положу на другую чашу весов:— реальное развитие языка, кто не верит — зайдите в репозиторий».
> А у языка и не должно быть плана развития. План развития должен быть у разработчиков языка. Интересно, откуда вам вообще знать, что есть у Зенда, а чего у них нет.
Для этого достаточно зайти в любой, связанный непосредственно с Zend'ом и PHP ресурс.
Передергивание — это говорить, что план развития должен быть не у языка, а у разработчиков.
> Сейчас меня интересуют две вещи: а) распространенность платформы
Увы, он распространен
> и б) скорость разработки
Скорость разработки на РНР ниже, чем на тех же Питоне, Руби или даже Erlang'е.
> может быть тогда я и озадачусь Эрлангом, который вы возвели в статус НепогрешимоТруъПапских языков
Я уже говорил, что телепаты могут отправляться пешим строем в сад. Ничего я никуда не возводил.
Итак. С вашей стороны — сплошная демагогия и толпа аналогий, которая к делу не имеет ни малейшего отношения.
Теперь факты:
— Язык развивается абсолютно хаотично. В язык пачками добавляются фундаментальные или кардинально меняющие язык вещи без какой-либо системы. Переход 5.2->5.3 и переход 5.3->5.4 содержит на порядок большее количество изменений (причем кардинальных), чем планируемый(?) переход 5.x->5.6. Это — факт. Спорить с этим — это говорить, что днем темно, а ночью светло.
— В языке могут спокойно соседствовать «фичи», которые, по сути, выполняют одно и то же, но при этом несовместимы друг с другом и не обеспечивают полный набор функциональности. Ближайший пример — три(!) способа работы с MySQL, и все — в стандартной поставке. Не в виде отдельных библиотек, что было бы понятно, а в стандартной поставке. Это — факт. И то, что это — идиотизм — это тоже факт. Достаточно взглянуть на уже приводимую здесь таблицу:
Они несовместимы между собой, каждый из способов в отдельности не обеспечивает полного набора фич — это факт. То, что это бардак — это факт. То, что он вообще существует говорит только подтверждает, что развитие языка происходит хаотично.
Это делает использование языка (языка! не фреймворков и библиотек, а языка) мягко говоря затруднительным. Потому что надо постоянно держать в голове не только разницу между реализующими одно и то же, но разными, возможностями языка, но еще и разницу между каждой минорной версией языка — а это звиздец.
Правда, человеку, который бахвалится тем, что эти недостатки он исправляет фреймворками, это не понять.
Зато те люди, которым эти фреймворки приходится писать, — им надо памятники ставить за то количество оберток, абстракций и прочих велосипедов, которые приходится создавать, чтобы всю эту кривизну обходить. Ближайший пример: «Abstract class to emulate a PDOStatement for native database adapters». Не было бы бардака в адаптерах, не пришлось бы писать эмулятор.
Ну и ты ды и ты пы.
Хорошо. Что именно я должен увидеть в репозитории? Восстанавливаю контекст: «А я вот положу на другую чашу весов:— реальное развитие языка, кто не верит — зайдите в репозиторий».
> А у языка и не должно быть плана развития. План развития должен быть у разработчиков языка. Интересно, откуда вам вообще знать, что есть у Зенда, а чего у них нет.
Для этого достаточно зайти в любой, связанный непосредственно с Zend'ом и PHP ресурс.
Передергивание — это говорить, что план развития должен быть не у языка, а у разработчиков.
> Сейчас меня интересуют две вещи: а) распространенность платформы
Увы, он распространен
> и б) скорость разработки
Скорость разработки на РНР ниже, чем на тех же Питоне, Руби или даже Erlang'е.
> может быть тогда я и озадачусь Эрлангом, который вы возвели в статус НепогрешимоТруъПапских языков
Я уже говорил, что телепаты могут отправляться пешим строем в сад. Ничего я никуда не возводил.
Итак. С вашей стороны — сплошная демагогия и толпа аналогий, которая к делу не имеет ни малейшего отношения.
Теперь факты:
— Язык развивается абсолютно хаотично. В язык пачками добавляются фундаментальные или кардинально меняющие язык вещи без какой-либо системы. Переход 5.2->5.3 и переход 5.3->5.4 содержит на порядок большее количество изменений (причем кардинальных), чем планируемый(?) переход 5.x->5.6. Это — факт. Спорить с этим — это говорить, что днем темно, а ночью светло.
— В языке могут спокойно соседствовать «фичи», которые, по сути, выполняют одно и то же, но при этом несовместимы друг с другом и не обеспечивают полный набор функциональности. Ближайший пример — три(!) способа работы с MySQL, и все — в стандартной поставке. Не в виде отдельных библиотек, что было бы понятно, а в стандартной поставке. Это — факт. И то, что это — идиотизм — это тоже факт. Достаточно взглянуть на уже приводимую здесь таблицу:
Они несовместимы между собой, каждый из способов в отдельности не обеспечивает полного набора фич — это факт. То, что это бардак — это факт. То, что он вообще существует говорит только подтверждает, что развитие языка происходит хаотично.
Это делает использование языка (языка! не фреймворков и библиотек, а языка) мягко говоря затруднительным. Потому что надо постоянно держать в голове не только разницу между реализующими одно и то же, но разными, возможностями языка, но еще и разницу между каждой минорной версией языка — а это звиздец.
Правда, человеку, который бахвалится тем, что эти недостатки он исправляет фреймворками, это не понять.
Зато те люди, которым эти фреймворки приходится писать, — им надо памятники ставить за то количество оберток, абстракций и прочих велосипедов, которые приходится создавать, чтобы всю эту кривизну обходить. Ближайший пример: «Abstract class to emulate a PDOStatement for native database adapters». Не было бы бардака в адаптерах, не пришлось бы писать эмулятор.
Ну и ты ды и ты пы.
НЛО прилетело и опубликовало эту надпись здесь
> Вот вы привязались к php_mysql. Ну убрали его, убрали. Работа над ошибками — это тоже работа.
Угу. Вот только что им мешало не вводить две сущности — mysqli и PDO — в одной и той же версии PHP, а ввести только одну, но грамотно сделанную? Та самая «работа над ошибками»?
Судя по тому, как вы пропустили весь текст про хаотичную разработку, вам на это возразить нечего, ведь действительно, с фактами не поспоришь.
> Получается, что я бахвалюсь тем, что использую фреймворки, а вы меня за это как бы осуждаете. Ну и как же, позвольте, мне создать приложение, которое имело бы стройную структуру (и да — купировало бы некоторые ляпы языка)? Как же я создам бизнес логику без фреймворков (которыми можно что угодно назвать)?
Вот только не надо придумывать за меня то, что я не говорил. Цитирую вас:
Так вот, человек, который работает не только с фреймворками, прекрасно понимает, какой хаос творится в РНР. И этот хаос не убрать ни фреймворками, ни архитектурой. Потому что (а это уже мои слова):
> Ну так удивите меня, мне же интересно… вокруг куча народа опытнее и умнее меня — мне же интересно их мнение. А вы все не говорите да не говорите…
Если бы вы уще умели читать, что вам пишут, было бы совсем хорошо.
На протяжении нашего разговора вы раз за разом решили, что я говорю про Питон, Руби и Erlang. Хотя я ни раз уне говорил ни про одно, ни про другое, ни про третье (кроме как в ответах на ваш хреново работающий телепатор).
Есть языки, на которых разработка приятнее и быстрее, чем на PHP. Для того, чтобы это знать, надо высунуть голову из любимых фреймворков, сделать над собой усилие и поработать с этими другими языками.
Уже упомянутые Руби и Питон как языки на голову выше PHP по удобству использования, Erlang — на порядок выше PHP и по удобству и качеству.
Фреймворки на Ruby и Python'у чаще лучше по качеству, удобству и быстроте разработки, чем аналогичные на PHP. Что не удивительно. PHP обзавелся более-менее нормальными фреймворками чуть ли не последним среди мейнстримных языков. Для Erlang'а ситуация хуже, но для REST'а ничего лучше Webmachine не придумано.
Если вы зарабатываете на РНР, ничего в этом зазорного нет, я тоже на нем зарабатываю (уже 10 лет как). Но настаивать на том, что это — хороший язык… Увольте.
> Предположим, кто-то (внешне похожий на меня, но не я) погрузился в PHP и варится в нем 24х7. Изучить другой язык — изучил, но в силу особенностей (распространенность как платформ, так и разработчиков) языка ничего другого ему не остается — как использовать PHP и дальше.
Если человек 24x7 варится в РНР, этот человек — идиот. Потому что вне работы можно найти себе более интересные (и с точки зрения программирования тоже) занятия.
> вдоволь нахлебался собственных велосипедов. Стремится к ликвидации энтропии в написанных приложениях — и для этого использует фреймворки… Так в чем же человек не прав и что, в конце концов, вы хотите доказать то?
— Неправ в том, что занимается РНР 24x7
— Неправ в том, что убогость языка и хаотичность его развития можно прикрыть фреймворками
— Неправ в том, что продолжает защищать этот язык, не приведя ни единого факта, а опираясь только на демагогию (кстати, о демагогии: вопрос про репозиторий так и остался открытым)
> Ну не согласны вы… ну наймитесь в Зенд, да ликвидируйте все хреновости в языке уже, наконец…
Мне больше делать нечего? У меня в жизни (программерской) есть гораздо более интересные задачи, чем попытка выправления хаоса.
Угу. Вот только что им мешало не вводить две сущности — mysqli и PDO — в одной и той же версии PHP, а ввести только одну, но грамотно сделанную? Та самая «работа над ошибками»?
Судя по тому, как вы пропустили весь текст про хаотичную разработку, вам на это возразить нечего, ведь действительно, с фактами не поспоришь.
> Получается, что я бахвалюсь тем, что использую фреймворки, а вы меня за это как бы осуждаете. Ну и как же, позвольте, мне создать приложение, которое имело бы стройную структуру (и да — купировало бы некоторые ляпы языка)? Как же я создам бизнес логику без фреймворков (которыми можно что угодно назвать)?
Вот только не надо придумывать за меня то, что я не говорил. Цитирую вас:
Лично для меня (буду общаться на понятном вам языке) «убожество» PHP в некоторых аспектах искореняется использованием фреймворков и выбором правильной архитектуры приложения
Так вот, человек, который работает не только с фреймворками, прекрасно понимает, какой хаос творится в РНР. И этот хаос не убрать ни фреймворками, ни архитектурой. Потому что (а это уже мои слова):
Это делает использование языка (языка! не фреймворков и библиотек, а языка) мягко говоря затруднительным. Потому что надо постоянно держать в голове не только разницу между реализующими одно и то же, но разными, возможностями языка, но еще и разницу между каждой минорной версией языка — а это звиздец.
> Ну так удивите меня, мне же интересно… вокруг куча народа опытнее и умнее меня — мне же интересно их мнение. А вы все не говорите да не говорите…
Если бы вы уще умели читать, что вам пишут, было бы совсем хорошо.
На протяжении нашего разговора вы раз за разом решили, что я говорю про Питон, Руби и Erlang. Хотя я ни раз уне говорил ни про одно, ни про другое, ни про третье (кроме как в ответах на ваш хреново работающий телепатор).
Есть языки, на которых разработка приятнее и быстрее, чем на PHP. Для того, чтобы это знать, надо высунуть голову из любимых фреймворков, сделать над собой усилие и поработать с этими другими языками.
Уже упомянутые Руби и Питон как языки на голову выше PHP по удобству использования, Erlang — на порядок выше PHP и по удобству и качеству.
Фреймворки на Ruby и Python'у чаще лучше по качеству, удобству и быстроте разработки, чем аналогичные на PHP. Что не удивительно. PHP обзавелся более-менее нормальными фреймворками чуть ли не последним среди мейнстримных языков. Для Erlang'а ситуация хуже, но для REST'а ничего лучше Webmachine не придумано.
Если вы зарабатываете на РНР, ничего в этом зазорного нет, я тоже на нем зарабатываю (уже 10 лет как). Но настаивать на том, что это — хороший язык… Увольте.
> Предположим, кто-то (внешне похожий на меня, но не я) погрузился в PHP и варится в нем 24х7. Изучить другой язык — изучил, но в силу особенностей (распространенность как платформ, так и разработчиков) языка ничего другого ему не остается — как использовать PHP и дальше.
Если человек 24x7 варится в РНР, этот человек — идиот. Потому что вне работы можно найти себе более интересные (и с точки зрения программирования тоже) занятия.
> вдоволь нахлебался собственных велосипедов. Стремится к ликвидации энтропии в написанных приложениях — и для этого использует фреймворки… Так в чем же человек не прав и что, в конце концов, вы хотите доказать то?
— Неправ в том, что занимается РНР 24x7
— Неправ в том, что убогость языка и хаотичность его развития можно прикрыть фреймворками
— Неправ в том, что продолжает защищать этот язык, не приведя ни единого факта, а опираясь только на демагогию (кстати, о демагогии: вопрос про репозиторий так и остался открытым)
> Ну не согласны вы… ну наймитесь в Зенд, да ликвидируйте все хреновости в языке уже, наконец…
Мне больше делать нечего? У меня в жизни (программерской) есть гораздо более интересные задачи, чем попытка выправления хаоса.
Ах, и да, я ничего в своих сообщения ни про Руби ни про Питон не говорил.
Для тех кто читает через строки:
Говорится о прекращении поддержки расширения MySQL, а не отказ от неё!
MySQLi является улучшенной версией старого драйвера PHP MySQL, предлагающего различные улучшения
Говорится о прекращении поддержки расширения MySQL, а не отказ от неё!
MySQLi является улучшенной версией старого драйвера PHP MySQL, предлагающего различные улучшения
> в версии PHP 6 код этих функций будет, скорей всего, полностью удалён из PHP
Кто-нибудь вообще слышал о таком модном слове как «обратная совместимость». Тренд сезона, однако. Почему бы просто не сделать алиас с mysqli?
Кто-нибудь вообще слышал о таком модном слове как «обратная совместимость». Тренд сезона, однако. Почему бы просто не сделать алиас с mysqli?
НЛО прилетело и опубликовало эту надпись здесь
Поэтому настоящий PHP программист — экземпляр из красной книги, которого обычно отрывают с руками и он получает очень хорошую зарплату — по себе знаю, я кризиса даже не заметил, даже наоборот зарплату только подняли. Искали себе PHP гуру в комманду почти пол года — в итоге просто переманили на зарплату прилично побольше и гораздо более благоприятными условиями работы. Ибо свободных просто нету.
Ну и правильно делают что убирают mysql_* давно уже есть более правильный mysqli_*
А автору темы нужно гвоздь в голову вбить, чтобы такие заголовки не писаль больше.
А автору темы нужно гвоздь в голову вбить, чтобы такие заголовки не писаль больше.
Такие заголовки хорошо продаются — посмотрите на рейтинг :)
Рейтингуют те кто не прочитав полностью топик начинают делать выводы на своих догадках, не вникая в суть, я прочитав захотел поставить минус.
Вот яркий тому пример (http://habrahabr.ru/blogs/php/124245/#comment_4082757), я больше чем уверен что он поставил плюс только по заголовку.
Радует что таких не много.
Вот яркий тому пример (http://habrahabr.ru/blogs/php/124245/#comment_4082757), я больше чем уверен что он поставил плюс только по заголовку.
Радует что таких не много.
Надеюсь мануалы в сети обновят, чтоб случайно не напарываться на старые «уже нерабочие» варианты. Но я сторонник прогресса, если это во благо производительности/функционалу — значит надо менять!
С такими заголовками автору прямая дорога в Комсомольскую Правду.
А новость безусловно положительная. Я сам за собой замечаю использование mysql_ по старой памяти в мелкий утилитках. Теперь будет лишнее напоминание :)
А новость безусловно положительная. Я сам за собой замечаю использование mysql_ по старой памяти в мелкий утилитках. Теперь будет лишнее напоминание :)
А нахрена она нужна?
Это был ответ BiSeTrojanov'у. Промахнулся -_-
почитав заголовок и пару абзацев, я чуть было не обосрался
по ходу чтения отлягло, конечно
а вообще, выбросить старые драйвера это здравая мысль, кому они будут нужны через 2-3 года
по ходу чтения отлягло, конечно
а вообще, выбросить старые драйвера это здравая мысль, кому они будут нужны через 2-3 года
Правильное решение. Используйте современные решения и будет вам счастье.
небольшая неточность — нет таких функций mysqlnd. Это низкоуровневый драйвер нативной поддержи мускула. Он работает под слоем абстракции — mysqli или PDO, но никак не сам по себе.
Исправьте заголовок стать на
Прекращение поддержки функции mysql_ в PHP
Давно пора. php_pdo есть, mysqli есть. mysql_connect() и прочие уже давно моветон в среде профессиональных php'шников.
mysqli_connect() — такой же точно моветон :-P
вопрос не в том, каким экстеншеном ты пользуешься, а в том, используются ли в коде голые функции API.
вопрос не в том, каким экстеншеном ты пользуешься, а в том, используются ли в коде голые функции API.
Почему моветон? Какая разница, mysqli_connect или $pdo = new PDO, если вокруг все равно приходится писать обертку для lazy connect/logging/debugging/placeholders/fetchPairs() и прочих фичей?
Ну собственно вот по-этому имхо.
Стоило ожидать, сколько можно тянуть за собой старые санки, пора менять уже на снегоходы.
Ну что ж, вот и настала пора попрощаться с mysql и изучить более вкусные PDO и mysqli
значит хостинги будут массово переходить на SQLLite или PostgreSql
а то все сидят на mySql 5
заголовок — желтизна!
Разработчики на PHP должны сказать огромное спасибо разработчикам PHP, т.к. теперь возникнет официальная необходимость в ревизии огромного количества старого кода в случае желания/необходимости его использования в новых проектах. Для PHP-разработчиков это означает тысячи оплаченных человекочасов и тонны еды.
Я бы сказал, это такая социальная акция, гуманитарная помощь от разработчиков PHP по отношению к лояльному комьюнити.
Я бы сказал, это такая социальная акция, гуманитарная помощь от разработчиков PHP по отношению к лояльному комьюнити.
Наверное, так рассуждают все люди, котрым платят за реально бесполезные вещи. Еще популярно считать, что верстальщики должны быть благодарны ie6, за то что он увеличивает их работу на 50%.
Разница в том, что IE6 создает сложную работу, не всегда даже выполнимую. А переписывание пэхапэшника с использования одних функций на другие — это беспроигрышный вариант: работа простая, непыльная, несложная (но объемная) и при этом страшно нужная заказчику, т.к. если хостер ВНЕЗАПНО меняет у себя версию PHP, сайт приходит в нерабочее состояние.
Вот не надо было тянуть кота за хвост.
Она объёмная только если проектированием занимался конкретный быдлокодер.
Многие сайты (а особенно «сайтики») развивались/развиваются хаотически. Так что как раз этот случай.
Хм… я тоже хочу работу на которой платят за то что в каком-то говно-сайтике(в большинстве случаев) достаточно запустить Replace in Project и получить бабло за рефакторинг тысячи строчек говнокода :) Да ладно работу! Я хочу просто такое начальство которое не понимает сложности задания! :)
О чем вы? Какое начальство у фрилансеров?
О фрилансерах до этого коммента небыло ни слова… Потому я подразумевал программистов работающих в студиях и т.д.
Сам-то я не любитель бесполезной работы, но люди-то в веб-дизайне «деньги зарабатывают» ;-)
Верный шаг. Я думаю, что его не уберут полностью, оставят в PECL, чтоб кому надо мог собрать и подключить.
НЛО прилетело и опубликовало эту надпись здесь
Недавно перевёл свои «быдлопроекты» на php_mysqli. Так что это решение поддерживаю. У меня нет ничего крупного. Да и вообще синтаксис и возможности mysqili понравились. Если честно не меняя логики можно старый софт перевести на mysqli через awk. Да и не первый раз лопатить код приходится. Благо малые объёмы.
Хинт, как легко перейти на MySQLi: вы можете рекурсиво во всех файлах проекта заменить mysql_ на mysqli_, и, с большой вероятностью, всё будет работать.
Для
mysqli_real_escape_string не будет работать, там параметры почему то местами поменяли.
Не будет. connect требует указания БД, в query поменяны местами запрос и соединение, всякие штуки вроде отображения последней ошибки требуют аргументов соединение когда раньше работало без аргумента вообще и так далее.
>connect требует указания БД, в query поменяны местами запрос и соединение
Чо?
RTFM
ru.php.net/mysql_connect
ru.php.net/manual/en/mysqli.connect.php
Чо?
RTFM
ru.php.net/mysql_connect
ru.php.net/manual/en/mysqli.connect.php
Я сам сначала пользовался функциями mysql, затем перешел к mysqli, и в итоге пришел к PDO. И вследствии этого, не вижу ничего страшно в том, что в PHP 6 будет удален поддержка mysql-функций. К тому же к тому времени, когда PHP 6 станет повсеместно распространенным (как сейчас PHP 5.1-5.3), пройдет ещё немало времени, за которое проекты, использующие mysql-функции, либо загнутся, либо будут подправлены своими авторами.
Получается, что удаление mysql-функций — всего лишь дань прогрессу.
Получается, что удаление mysql-функций — всего лишь дань прогрессу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прекращение поддержки расширения MySQL в PHP