Comments 135
"P.S. Чур вопрос когда будет goto в PHP не предлагать.."
Уже анонсирован? 8)
Уже анонсирован? 8)
0
- Когда наведут порядок в названиях функций?
+4
Каких конкретно функций?
0
Ну это из разряда холивара вопрос.
Я имею ввиду неразбериху с именованием.
Например функции для работы с массивами начинаются на array_ но функция sort() почемуто не начинается.
Тоже самое касается строк. Например есть пачка функций начинающхся с str а есть такие которые начинаются на str_, и ещё есть такие которые без префиксов.
Не скажу что это критично, но было бы интуитивно понятнее если бы был какойто стандарт. Ну и вообще -стандарты это хорошо. Особенно это касается именования функций.
Я имею ввиду неразбериху с именованием.
Например функции для работы с массивами начинаются на array_ но функция sort() почемуто не начинается.
Тоже самое касается строк. Например есть пачка функций начинающхся с str а есть такие которые начинаются на str_, и ещё есть такие которые без префиксов.
Не скажу что это критично, но было бы интуитивно понятнее если бы был какойто стандарт. Ну и вообще -стандарты это хорошо. Особенно это касается именования функций.
0
насколько я помню там уже начинают вводить более правильные алиасы для имен.
0
ещё есть strip_tags() но stripslashes()
0
обратную совместимость в любом случае надо оставить. хостеры даже с 4 версии все еще не все перешли ;)
0
И разнесут их по классам, превратив в методы.
+1
— Назовите любимый трюк/необычное использование какой-то функции, которое вы когда либо видели.
— Будет ли множественное наследование наконец взято из зенд-ядра и добавлено в сам PHP?
— Когда наконец разберутся с __CLASS__? Нет ли идеи сделать вместо неё две функции: одну, в которой возвращается класс, в которой метод описан, и вторую, в которой возвращается реальный тип объекта? Если верить сообщениям тут, то поведение функции get_class, схожей по функционалу нестабильно, т.е. меняется от версии к версии, если верить комментам к странице.
— Будет ли множественное наследование наконец взято из зенд-ядра и добавлено в сам PHP?
— Когда наконец разберутся с __CLASS__? Нет ли идеи сделать вместо неё две функции: одну, в которой возвращается класс, в которой метод описан, и вторую, в которой возвращается реальный тип объекта? Если верить сообщениям тут, то поведение функции get_class, схожей по функционалу нестабильно, т.е. меняется от версии к версии, если верить комментам к странице.
0
исходя из описания php6 соответственно вопрос - синтаксис php аккуратно близится к синтаксису перла?
-2
когда можно будет писать такое?
element4 = getSmthList()[3]
element4 = getSmthList()[3]
+2
скорее всего никогда. вот сдесь велась дискуссия на эту тему: http://news.php.net/php.internals/start/… (Array access on function returns)
+1
А зачем? Чтобы все не было слишком просто? =]
0
Просто мне не понятны причины, по которым не работает.
getSmthList() - это массив, но почему-то не могу с него взять значение - это странно.
getSmthList() - это массив, но почему-то не могу с него взять значение - это странно.
0
Логически, возможно, Вы правы, но вот практически, это бережет кодеров от
$var_0 = getSomeVar()[0];
$var_1 = getSomeVar()[1];
$var_2 = getSomeVar()[2];
$var_3 = getSomeVar()[3];
т.к. это вызовет функцию 4 раза.
Т.е. либо получаем весь массив, либо не даем функции отдавать массив. Это удобно и практично, а если нужна логика надо использовать Си или производные от него ;-)
$var_0 = getSomeVar()[0];
$var_1 = getSomeVar()[1];
$var_2 = getSomeVar()[2];
$var_3 = getSomeVar()[3];
т.к. это вызовет функцию 4 раза.
Т.е. либо получаем весь массив, либо не даем функции отдавать массив. Это удобно и практично, а если нужна логика надо использовать Си или производные от него ;-)
0
что выведет на экран следующая конструкция?:
$arr = false;
echo count($arr);
$arr = false;
echo count($arr);
0
1
0
согласитесь что было бы логичнее если бы возвращало 0.
0
UFO just landed and posted this here
Если читать документацию, то понятно, что 1-й случай - фича, а второй - особенность оператора ==
0
Тут логичнее использовать ===
0
Тут все логично. При сравнении == оба операнда приводятся к одному типу (ведь только такие и имеет смысл сравнивать, ведь так?) В данном случае к int. 'String' в int - это 0.
0
Функция count() применима для массивов. А так как в языке слабая типизация, то $arr автоматически преобразовывается к массиву {0=>false}. В нем 1 элемент, вот и возвращается 1. Все верно.
+1
ужасти. 0 будет логичнее
0
Тогда будет куча труднонаходимых ошибок. Данным кодом я хочу узнать количество элементов $arr, а какие у него значения — совсем другое дело. Логично возвращать 0 — когда значение $arr NULL или array(), так сейчас и есть.
+1
Так это ведь не массив.
На мой взгляд, это тоже ведёт к появлению труднонаходимых ошибок.
Думаю, следует выводить нотис или стрикт при передаче count не массива и не объекта. Как считаете?
На мой взгляд, это тоже ведёт к появлению труднонаходимых ошибок.
Думаю, следует выводить нотис или стрикт при передаче count не массива и не объекта. Как считаете?
+1
Строка - это массив. Элементы такого массива - символы строки. И это как раз очень облегчает жизнь =)
0
Если вызвать $arr[1], где $arr = 'hello', мы получим 'e', т.е. строку можно с натяжкой назвать массивом, где элементы - символы. Хотя в данном случае, строка - это массив с одним элементом.
А вот это уже часто помогает не заморачивать себя проверками строка это или массив, при отсутствии жесткой типизации.
А вот это уже часто помогает не заморачивать себя проверками строка это или массив, при отсутствии жесткой типизации.
0
Строка очень похожа на массив.
Но для строки вместо count() есть strlen().
Но для строки вместо count() есть strlen().
0
а что вас удивляет? так может поможет?
$arr = false;
var_dump((array)$arr);
все эти глупые вопросы из-за незнания или непонимая type juggling... неужели вы думаете, что разработчики PHP и впрямь такие наивные идиоты?? поверьте, они на шаги впереди вас, предупреждая появление ошибок в ваших же скриптах, когда-нибудь вы это поймёте.
тут когда-то выступал один, тоже все рассказывал про «идиотизм в php», очень гордился тем, что перешел на python, хотя сам не понимал элементарных вещей в php. Наверное он сейчас и python уже забросил, видимо тоже из-за «идиотизмов в python»…
лично я
$arr = false;
var_dump((array)$arr);
все эти глупые вопросы из-за незнания или непонимая type juggling... неужели вы думаете, что разработчики PHP и впрямь такие наивные идиоты?? поверьте, они на шаги впереди вас, предупреждая появление ошибок в ваших же скриптах, когда-нибудь вы это поймёте.
тут когда-то выступал один, тоже все рассказывал про «идиотизм в php», очень гордился тем, что перешел на python, хотя сам не понимал элементарных вещей в php. Наверное он сейчас и python уже забросил, видимо тоже из-за «идиотизмов в python»…
лично я
0
хм.. откуда тут "лично я"... :) ну ладно, лично я люблю и php и python и бесконечно восторгаюсь гениальностью, усердием и трудолюбивостью создателей этих языков
0
Насчет гениальности создателей PHP я бы поспорил. Многовато косяков для языка с 13-летней историей.
-2
ну,создайте свой язык программирования. и давайте не будем... каких косяков?
+1
Чисто наскидку:
1. type-hinting в языке с неявной типизацией (Однако JS как-то работает без type-hinting, странно да?).
2. нет единого соглашения в именовании функций (знаю-знаю. исторически сложилось, ага).
3. нет единого соглашения по обработке ошибок. PHP применяет warnings, fatals, catchable fatals, exceptions. (тот же JS любую ошибку выполнения скрипта сводит к exception).
4. нет возможности использовать позднее статическое связывание (обещали в ветке 5.3, но где
этот релиз?).
5. передача по ссылке/значению. Почему объекты всегда передаются по ссылке, а массивы - нет?
6. autoload. Хуже решения проблемы отсутствия линковщика в PHP придумать сложно.
И после этого вы будете говорить, что PHP - самый самый? некоторые реализации JS на порядок качественнее сделаны, чем PHP.
1. type-hinting в языке с неявной типизацией (Однако JS как-то работает без type-hinting, странно да?).
2. нет единого соглашения в именовании функций (знаю-знаю. исторически сложилось, ага).
3. нет единого соглашения по обработке ошибок. PHP применяет warnings, fatals, catchable fatals, exceptions. (тот же JS любую ошибку выполнения скрипта сводит к exception).
4. нет возможности использовать позднее статическое связывание (обещали в ветке 5.3, но где
этот релиз?).
5. передача по ссылке/значению. Почему объекты всегда передаются по ссылке, а массивы - нет?
6. autoload. Хуже решения проблемы отсутствия линковщика в PHP придумать сложно.
И после этого вы будете говорить, что PHP - самый самый? некоторые реализации JS на порядок качественнее сделаны, чем PHP.
0
ваша конструкция приводит $arr к типу array а потом выводит его.
видимо по такому же алгоритму и работает count().
но не кажется ли вам что было бы логичнее вернуть 0 или false если $arr не массив?
видимо по такому же алгоритму и работает count().
но не кажется ли вам что было бы логичнее вернуть 0 или false если $arr не массив?
0
1. Зачем нам всем переходить на php6 (какие реальные преимущества кроме Unicode)?
2. Нет ли у разработчиков идеи отказаться от функций по работе с массивами, и перенести ВЕСЬ функционал, связанный с массивами в SPL?
3. Собираются ли разработчики расширять "влияние" PHP на соседние области: применение на десктопах, мобильных устройствах. То есть идти по пути Java.
4. Каково официальное мнение разработчиков PHP по поводу технологии .NET? Есть ли планы по интеграции .NET в приложения, написанные на PHP (jgznm же официальной, а не сторонними костылями)?
И наконец:
5. Как же все-таки пропатчить KDE2 под FreeBSD????
2. Нет ли у разработчиков идеи отказаться от функций по работе с массивами, и перенести ВЕСЬ функционал, связанный с массивами в SPL?
3. Собираются ли разработчики расширять "влияние" PHP на соседние области: применение на десктопах, мобильных устройствах. То есть идти по пути Java.
4. Каково официальное мнение разработчиков PHP по поводу технологии .NET? Есть ли планы по интеграции .NET в приложения, написанные на PHP (jgznm же официальной, а не сторонними костылями)?
И наконец:
5. Как же все-таки пропатчить KDE2 под FreeBSD????
+3
1) Когда будет нормальная работа с MSSQL
2) Будет ли создаваться БД SQL специально для PHP
2) Будет ли создаваться БД SQL специально для PHP
+1
2) Будет ли создаваться БД SQL специально для PHP
SQLite?
SQLite?
0
"Когда будет нормальная работа с MSSQL"
Уже.
Уже.
0
А ссылки можно на доки?
0
Вероятно, речь о Microsoft SQL Server 2005 Driver for PHP.
0
да уже есть нормальный, а также у microsoft c zend есть договорености, о совместной разработке драйвера.
0
очень хочется узнать о "настоящей" многопоточности в PHP.
0
UFO just landed and posted this here
zend engine и есть вирт.машина
если хочетцо "пощупать поближе" то: http://ru2.php.net/runkit
если хочетцо "пощупать поближе" то: http://ru2.php.net/runkit
0
UFO just landed and posted this here
почему нет нормального корного фриварного компилятора в байт код с последующим использованием этого байт-кода?
+4
Потому что любой тогда сможет написать свой энкодер и никто не будет покупать зендовский за ~1000 баксов...
0
нет, я не о том, что каждый может писать. Пусть код будет зашифрован понятным только этому энкодеру способом.
тогда вопрос в другом, сколько % получают разработчики ядра php при продаже зедновского энкодера?
тогда вопрос в другом, сколько % получают разработчики ядра php при продаже зедновского энкодера?
0
Потому что Зенду невыгодно )
-1
Будет ли когда нибудь строгое типизирование (список параметров и тип возвращаемого результата), полиморфизм.
PS: ведется ли оптимизация самого PHP, хотя это может решится, если будет сделано что-то типа байткода в Java, возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
PS: ведется ли оптимизация самого PHP, хотя это может решится, если будет сделано что-то типа байткода в Java, возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
+2
>Будет ли когда нибудь строгое типизирование (список параметров и тип возвращаемого результата), полиморфизм.
Строгое типизирование уже есть для массива, для остальных типов - противоречит основным идеям РНР.
Полиморфизм - тоже.
>возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
Zend Encoder, Zend Optimizer, eAccelerator и т.д. не подходят?
Строгое типизирование уже есть для массива, для остальных типов - противоречит основным идеям РНР.
Полиморфизм - тоже.
>возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
Zend Encoder, Zend Optimizer, eAccelerator и т.д. не подходят?
0
компиляторы очень дорогие
0
и не стандартизированы совсем
0
Не только для массивов, но и для объектов. Нет для простых типов, таких как int, string и т.д....
0
> Zend Encoder, Zend Optimizer, eAccelerator и т.д. не подходят
Это не совсем то, чего хотелось бы. Например на локальной машине я буду использовать код в текстовом виде, а на продакшн мне бы хотелось не ставить доп. програмы, а скомпилить весь сайт и залить. Это прирост в скорости работы и без разных дополнений. ИМХО это было бы удобно
Это не совсем то, чего хотелось бы. Например на локальной машине я буду использовать код в текстовом виде, а на продакшн мне бы хотелось не ставить доп. програмы, а скомпилить весь сайт и залить. Это прирост в скорости работы и без разных дополнений. ИМХО это было бы удобно
0
а разве полиморфизм в PHP отсуствует? Абстрактные классы, интерфейсы.
0
на сколько я знаю я не могу написать draw(Cicrle $c) {...} и draw(Line $l) в одном и том-же класе. Конечно, это ограничение обойти можноЮ но это костыли - не лучше ли сделать это на уровне ядра )
по поводу строгого типизирования - не могу сказать как это отразится на скорости, но может можно объединить оба подхода? во многих ситуациях типизирование полезно, но как я уже сказал - возможно это сильно отразится на скорости, а если так - то не надо ), хотя оптимизаторы байт-кода могут это хорошо оптимизировать.
по поводу строгого типизирования - не могу сказать как это отразится на скорости, но может можно объединить оба подхода? во многих ситуациях типизирование полезно, но как я уже сказал - возможно это сильно отразится на скорости, а если так - то не надо ), хотя оптимизаторы байт-кода могут это хорошо оптимизировать.
0
можешь.
если Circle и Line наследники одного родителя Figure, то function draw(Figure $fig); очень даже работает
если Circle и Line наследники одного родителя Figure, то function draw(Figure $fig); очень даже работает
0
в PHP типы int, float, string являются классами такими же как и stdObject, Array (то есть не атомарные как в С) и мне тоже вот не понятно, почему нельзя сделать строгую типизацию.
0
>ограничение обойти можноЮ но это костыли
Это не костыли, а просто "не так, как вы привыкли". Если, конечно, мы думаем об одном и том же способе применения полиморфизма.
Быть может, код, предлагаемый вами, красивее (хотя это тоже спорно). Но говорить, что PHP не поддерживает полиморфизм - глупо.
Строгое типизирование. Зачем? Это РНР, а не С. В РНР есть множество функций приведения типов, использование которых очень удобно.
Это не костыли, а просто "не так, как вы привыкли". Если, конечно, мы думаем об одном и том же способе применения полиморфизма.
Быть может, код, предлагаемый вами, красивее (хотя это тоже спорно). Но говорить, что PHP не поддерживает полиморфизм - глупо.
Строгое типизирование. Зачем? Это РНР, а не С. В РНР есть множество функций приведения типов, использование которых очень удобно.
0
Это лишний код - определение типа. Если этот код на C - он быстрее чем вызов ф-ции на PHP
0
Может я ошибаюсь, но draw(Figure $fig) а не draw(Cicrle $c) {...} и draw(Line $l) {...} - это не полиморфизм
0
Полиморфизм, как и остальные принципы и паттерны ООП, в большей степени зависят от программиста, и в меньшей - от языка.
В сторону РНР4 можно плюнуть за то, что он предельно слабо поддерживает ООП, с этим я согласен. Но РНР5 реализует основные принципы ООП, это главное. При этом можно смело сказать, что РНР - не на 100% ОО-язык, как C++ и Java, и требовать от него повторения каждой возможности этих языков нельзя. Каждый язык своеобразен, иначе их называли бы одинаково :)
"Не полиморфизм" - это Code Monkey вместо программиста или паскаль вместо языка.
В сторону РНР4 можно плюнуть за то, что он предельно слабо поддерживает ООП, с этим я согласен. Но РНР5 реализует основные принципы ООП, это главное. При этом можно смело сказать, что РНР - не на 100% ОО-язык, как C++ и Java, и требовать от него повторения каждой возможности этих языков нельзя. Каждый язык своеобразен, иначе их называли бы одинаково :)
"Не полиморфизм" - это Code Monkey вместо программиста или паскаль вместо языка.
0
С каких пор Java и C++ являются 100% ОО-языками? Имхо, единственный толковый 100% ОО-язык
это Smalltalk. Все остальное - вариации на тему.
И, кстати, что вы лично имеете против паскаля? Уточню: против Borland Pascal? ;-)
это Smalltalk. Все остальное - вариации на тему.
И, кстати, что вы лично имеете против паскаля? Уточню: против Borland Pascal? ;-)
0
Согласен, несколько ошибся :)
Но это дела не меняет.
Ну, паскаль я не люблю ещё с учёбы - личная взаимная неприязнь :)
Для понимания основ программирования - самое то. Но полиморфизма на нём я и представить не могу :)
Но это дела не меняет.
Ну, паскаль я не люблю ещё с учёбы - личная взаимная неприязнь :)
Для понимания основ программирования - самое то. Но полиморфизма на нём я и представить не могу :)
0
Возможно я Вас удивлю, но паскаль (Borland Pascal) очень даже позволяет делать полиморфизм, потому что полиморфизм - основа основ ООП, наряду с инкапсуляцией и наследованием. Если рассматривать дотошно, то некоторые вещи в BP реализованы удачнее, чем в C++. Видимо нелюбовь к паскалю у Вас сложилась из-за его морального устаревания к моменту, когда вы стали его изучать. А зря.
0
Ошибаетесь. Полиморфизм как раз таки использовать draw(Figure $fig). То, что вы подразумеваете под полиморфизмом - называется перегрузка методов :)
0
раз уж вопрос в деньгах и компилятор из области анриал, то какие механизмы ускорения обработки и опримизации кода будут добавлены?
0
Может добавить поддержку чего-нибудь наподобие:
Реализовать это возможно... тот же самый "include" только в теле документа.
PHP от этого не пострадает, разработчики ж спасибо скажут. Нужно идти на шаг вперёд, пока кто-нибудь не реализовал (наверное) подобное .
Реализовать это возможно... тот же самый "include" только в теле документа.
PHP от этого не пострадает, разработчики ж спасибо скажут. Нужно идти на шаг вперёд, пока кто-нибудь не реализовал (наверное) подобное .
0
Имелось ввиду:
0
Глюк какой то... сорри - смотрим выше видим следующее:
<?perl ... ?>
<?ruby ... ?>
<?python ... ?>
<?perl ... ?>
<?ruby ... ?>
<?python ... ?>
0
Нифига себе!!! А зачем такое?
Типа страничка HTML, в которую встроен код PHP, в который встроен код Ruby???
Связка HTML+PHP в одном флаконе (в одном файле) уже породила миллионы быдлокодеров и перлы индийского кода, а Вы хотите еще усугубить эту ситуацию???
Типа страничка HTML, в которую встроен код PHP, в который встроен код Ruby???
Связка HTML+PHP в одном флаконе (в одном файле) уже породила миллионы быдлокодеров и перлы индийского кода, а Вы хотите еще усугубить эту ситуацию???
+1
Не так: HTML => [ php | rubu | perl | python ] - это в идеале.
Для авторов PHP для PHPConf предложение: PHP => [ rubu | perl | python ] - чтобы начать с чего то.
На счёт связки HTML+PHP и "быдлокодеров".
Вот так реализуется связка (правда другая) в SHTML (POST не поддерживается):
<!--#include virtual="/cgi-bin/script.cgi?$QUERY_STRING"-->
А это уже PHP (С поддержкой POST, с извратом его передачи в script.cgi):
<?php
include ("/cgi-bin/script.cgi?$QUERY_STRING");
?>
И что? Да это удобно, но не всем и не во всём :)
Подумайте, что было бы если работала вышеприведённая связка, думайте не в сторону "быдлокодеров" в другую - ибо писать можно хорошо или просто ужастно на любых языках программирования.
Для авторов PHP для PHPConf предложение: PHP => [ rubu | perl | python ] - чтобы начать с чего то.
На счёт связки HTML+PHP и "быдлокодеров".
Вот так реализуется связка (правда другая) в SHTML (POST не поддерживается):
<!--#include virtual="/cgi-bin/script.cgi?$QUERY_STRING"-->
А это уже PHP (С поддержкой POST, с извратом его передачи в script.cgi):
<?php
include ("/cgi-bin/script.cgi?$QUERY_STRING");
?>
И что? Да это удобно, но не всем и не во всём :)
Подумайте, что было бы если работала вышеприведённая связка, думайте не в сторону "быдлокодеров" в другую - ибо писать можно хорошо или просто ужастно на любых языках программирования.
0
Да, но, извините, зачем???
Зачем писать проект на 3-х разных языках???
Ведь это же соблазн захламления кода.
Пока у Вас есть возможность, но она неудобна, вы будете вынуждены
использовать ее редко и, как следствие, обдуманно, продумывая архитектуру приложения.
Даже если у Вас в команде программисты с разными языками Вы вынуждены будете заставлять их писать нормальные модули, а потом использовать их, а не тупо лепить вставки кода на разных языках...
Зачем писать проект на 3-х разных языках???
Ведь это же соблазн захламления кода.
Пока у Вас есть возможность, но она неудобна, вы будете вынуждены
использовать ее редко и, как следствие, обдуманно, продумывая архитектуру приложения.
Даже если у Вас в команде программисты с разными языками Вы вынуждены будете заставлять их писать нормальные модули, а потом использовать их, а не тупо лепить вставки кода на разных языках...
0
Попытаюсь объяснить кратко.
Я лично пишу на Perl, а PHP лишь знаю образно. Желания переходить на PHP нет (но это не значит, что он хуже, он просто ДРУГОЙ), хотя у него я вижу (для меня) два основных преимущества при работе с HTML:
1. Эта самая "связка" HTML+PHP в одном флаконе" - не нужно плодить файлы.
2. Упрощённый вывод данных POST и GET - иногда не нужны сложности.
Из вышесказанного следует, что лично меня бы связка HTML+PERL вполне устроила, в крайнем случае PHP+PERL (PHP использовал бы только для print'а).
Но дело не только в этом. Довольно много модулей у нас на Perl, может уже побольше на PHP, не знаю. Реализованное в одном языке программирования не всегда реализовано в другом. Таким вот образом возможно было бы частично решить проблему.
Я лично пишу на Perl, а PHP лишь знаю образно. Желания переходить на PHP нет (но это не значит, что он хуже, он просто ДРУГОЙ), хотя у него я вижу (для меня) два основных преимущества при работе с HTML:
1. Эта самая "связка" HTML+PHP в одном флаконе" - не нужно плодить файлы.
2. Упрощённый вывод данных POST и GET - иногда не нужны сложности.
Из вышесказанного следует, что лично меня бы связка HTML+PERL вполне устроила, в крайнем случае PHP+PERL (PHP использовал бы только для print'а).
Но дело не только в этом. Довольно много модулей у нас на Perl, может уже побольше на PHP, не знаю. Реализованное в одном языке программирования не всегда реализовано в другом. Таким вот образом возможно было бы частично решить проблему.
0
"лично для меня" если для себя то да.
а клиенту как такое "фтюхивать"?
а клиенту как такое "фтюхивать"?
0
Разве клиент (заказчик) прописывает в договоре (ТЗ), что ему выдай всё на PHP пожалуйста?
0
да канечно, не знаю как, но у нас в договоре есть пункт "технические требования".
и для командной разработки этот венегрет просто не годится. (:
и для командной разработки этот венегрет просто не годится. (:
0
Согласен - слишком сложно для клиента.
Но если вернуться к вопросам авторам PHP, то меня бы венегред из PHP и PERL устроил :)
А интересно получается:
<?php
while (list($key, $val) = each($_POST)) {
$post_text = "$val"; // Допустим у нас одна форма с текстом
}
?>
...
<?perl
# Обозначаем в тексте гиперссылки;
$post_text =~ s|(http://.[^\ ]+)|<A href=\"$1\">$1|g;
?>
...
<?php
echo "$post_text";
?>
Но если вернуться к вопросам авторам PHP, то меня бы венегред из PHP и PERL устроил :)
А интересно получается:
<?php
while (list($key, $val) = each($_POST)) {
$post_text = "$val"; // Допустим у нас одна форма с текстом
}
?>
...
<?perl
# Обозначаем в тексте гиперссылки;
$post_text =~ s|(http://.[^\ ]+)|<A href=\"$1\">$1|g;
?>
...
<?php
echo "$post_text";
?>
0
бугага, ну если сильно хочется - модуль для апача написать не сложно. (: думаю это уже ктото написал (:
0
Когда будут неймспейсы?!
+1
Когда мы получим возможность разрабатывать на PHP полноценные серверы приложений а-ля Tomcat/Java servlets вместо одноразовых "скриптов"?
+2
Имеет ли смысл перенести функционал некоторых паттернов (например Singleton) в php?
+2
хотелось бы, чтобы при объявлении функции можно было указать типы входных аргументов..
если аргумент пришел другого типа - сразу warning
к примеру:
myfunction(string $a, array $b, integer $c, object $d){......}
если аргумент пришел другого типа - сразу warning
к примеру:
myfunction(string $a, array $b, integer $c, object $d){......}
0
Не думаю, что это призыв к переходу на строгую типизацию в PHP, а для аргументов функций и методов это в отдельных случаях действительно могло бы быть полезно.
0
Есть способ это сымитировать, достаточно простой и удобный:
1) убираем E_RECOVERABLE_ERROR из основного потока;
2) в функции-отловщике ошибок делаем switch от кода ошибки;
3) если пришёл E_RECOVERABLE_ERROR, проверяем строку ошибки на соответствие вот так:
Сразу говорю — использовал вполне удачно, но использовать очень часто не рекомендую: сотня-полторы таких вызовов вполне могут начать тормозить скрипт на несколько ms.
1) убираем E_RECOVERABLE_ERROR из основного потока;
error_reporting ((E_ALL | E_STRICT)&~E_RECOVERABLE_ERROR);
set_error_handler('send_error',E_STRICT | E_ALL);
2) в функции-отловщике ошибок делаем switch от кода ошибки;
function send_error($msg,$str,$file,$line,$context){
if(error_reporting())
switch($msg)
{
case E_RECOVERABLE_ERROR:
send_recoverable_error($msg,$str,$file,$line,$context);
break;
default:
………
}
}
3) если пришёл E_RECOVERABLE_ERROR, проверяем строку ошибки на соответствие вот так:
function send_recoverable_error($msg,$str,$file,$line,$context){
if(!preg_match('#instance of ([\w0-9_:]+), (\\1) given#', $str))
die('Тайпхинтинг нах… файл '.$file.' строка '.$line);
}
Сразу говорю — использовал вполне удачно, но использовать очень часто не рекомендую: сотня-полторы таких вызовов вполне могут начать тормозить скрипт на несколько ms.
0
когда появится кастинг !?
не преобразование (int)'123asd' (->123), а просто как подсказка IDE(и компилятору!?) с каким "типом" я собираюсь в данный момент работать.
хочется удобства в ситуациях вроде такой:
$customClassInstance = (CustomClass)unserialize($str);
и тут-же в IDE в автокомплите видеть методы CustomClass, а не «фигпоймчего»...
не преобразование (int)'123asd' (->123), а просто как подсказка IDE(и компилятору!?) с каким "типом" я собираюсь в данный момент работать.
хочется удобства в ситуациях вроде такой:
$customClassInstance = (CustomClass)unserialize($str);
и тут-же в IDE в автокомплите видеть методы CustomClass, а не «фигпоймчего»...
+1
На всякий случай озвучу в качестве самостоятельного вопроса.
Планируется ли полный переход на ООП на уровне встроенных функций путём создания систематизированной совокупности стандартных классов и превращения встроенных функций в методы этих классов? Например, все функции с префиксом array_ этого префикса лишатся и станут методами класса array. Про 5.3 не говорю, но хотя бы в шестёрке или, ммм… будущих версиях.
И попутно: как насчёт перехода на более традиционный ныне «верблюжий» синтаксис (подобно используемому в JavaScript или, например, при работе с DOM-расширением в PHP5)? Например, применительно к потенциальному объекту array метод мог бы называться walkRecursive вместо walk_recursive.
Спасибо.
Планируется ли полный переход на ООП на уровне встроенных функций путём создания систематизированной совокупности стандартных классов и превращения встроенных функций в методы этих классов? Например, все функции с префиксом array_ этого префикса лишатся и станут методами класса array. Про 5.3 не говорю, но хотя бы в шестёрке или, ммм… будущих версиях.
И попутно: как насчёт перехода на более традиционный ныне «верблюжий» синтаксис (подобно используемому в JavaScript или, например, при работе с DOM-расширением в PHP5)? Например, применительно к потенциальному объекту array метод мог бы называться walkRecursive вместо walk_recursive.
Спасибо.
+1
Давайте их сначала отберем. Я путаюсь в этой простыне :-(
P.S. Программа опбуликована сегодня..
http://www.phpconf.ru/programm/
P.S. Программа опбуликована сегодня..
http://www.phpconf.ru/programm/
0
1. Резюмируя множественные вопросы о компиляторах в байткод и подобном: Какой баланс собираются авторы PHP соблюдать между коммерческой выгодностью и общественной доступностью PHP? Есть ли такой баланс вообще (в смысле обозначен ли он, или всё решается раз от раза, на ходу)? Не дойдёт ли коммерциализация PHP до уровня MySQL & utilities, в которых for free можно получить только минимум "достаточный и необходимый", а всё остальное уже moneyware.
2. PHP часто критикуют за исторически сложившийся разброд именований (функций, констант) и за перегруженный global namespace. Собственно, вопрос не в том, когда, а в том, какие рассматриваются пути решения этой проблемы самими разработчиками? Какие имеют шансы на успех и на какие "делать ставки", формируя свои собственные стили кодирования? namespace per module? namespace per entity? или может даже вложенные namespaces? Или есть что-то более красивое?
3. В продолжение предыдущего вопроса. Может быть всё-таки пожертвовать обратной совместимостью ради будущего развития? Кардинально и радикально. Хотя бы на этапе смены major-версии. Хотя бы разово между 5 и 6, или между 6 и 7 версиями. Реально заметно как тяжёл стал для PHP груз совместимости.
4. Какие у вас там планы по популяризации языка? Его внедрение в массы за рамками webdev'а? Расширение роли и доли в webdev'е? Внедрение в корпоративные мегасистемы? Или всё оставлено на самотёк?
5. Немножко наивный вопрос. Так как язык PHP сейчас позиционируется как webdev-язык (та же HTML+PHP интеграция), то в свете наступающего "вебдваноля" и прочего сложно-структурного программирования, будет ли развиваться сам язык (ну или его дефолтная комплектация) в сторону упрощения всеё это "социальной" разработки и манипулирования сущностями более высокого порядка, чем массивы, переменные и даже объекты (например, сервисы, "родное" внедрение всяких ORM'ов, REST'ов и т.п; вполне так возможно что и средствами этих самых функций-массивов-переменных-объектов); или же эта область оставлена на откуп фреймворкам и язык ни в коем случае ради таких веяний моды меняться не будет? Не боитесь ли в таком случае проиграть языкам вроде Python & Rails, для которых есть практически неотлучные от них фреймворки (Ruby on Rails), из-за которых код на этих языках для одного и того же проекта в разы меньше, чем на PHP?
Вот, пожалуй, всё. На пока что.
2. PHP часто критикуют за исторически сложившийся разброд именований (функций, констант) и за перегруженный global namespace. Собственно, вопрос не в том, когда, а в том, какие рассматриваются пути решения этой проблемы самими разработчиками? Какие имеют шансы на успех и на какие "делать ставки", формируя свои собственные стили кодирования? namespace per module? namespace per entity? или может даже вложенные namespaces? Или есть что-то более красивое?
3. В продолжение предыдущего вопроса. Может быть всё-таки пожертвовать обратной совместимостью ради будущего развития? Кардинально и радикально. Хотя бы на этапе смены major-версии. Хотя бы разово между 5 и 6, или между 6 и 7 версиями. Реально заметно как тяжёл стал для PHP груз совместимости.
4. Какие у вас там планы по популяризации языка? Его внедрение в массы за рамками webdev'а? Расширение роли и доли в webdev'е? Внедрение в корпоративные мегасистемы? Или всё оставлено на самотёк?
5. Немножко наивный вопрос. Так как язык PHP сейчас позиционируется как webdev-язык (та же HTML+PHP интеграция), то в свете наступающего "вебдваноля" и прочего сложно-структурного программирования, будет ли развиваться сам язык (ну или его дефолтная комплектация) в сторону упрощения всеё это "социальной" разработки и манипулирования сущностями более высокого порядка, чем массивы, переменные и даже объекты (например, сервисы, "родное" внедрение всяких ORM'ов, REST'ов и т.п; вполне так возможно что и средствами этих самых функций-массивов-переменных-объектов); или же эта область оставлена на откуп фреймворкам и язык ни в коем случае ради таких веяний моды меняться не будет? Не боитесь ли в таком случае проиграть языкам вроде Python & Rails, для которых есть практически неотлучные от них фреймворки (Ruby on Rails), из-за которых код на этих языках для одного и того же проекта в разы меньше, чем на PHP?
Вот, пожалуй, всё. На пока что.
0
Когда будет реализовано (и будет ли):
class A {
private $obj = new Object();
}
вместо того, что бы в кострукторе создавать объект.
class A {
private $obj = new Object();
}
вместо того, что бы в кострукторе создавать объект.
+1
UFO just landed and posted this here
SPHINX: как растет производительность индексов типа gist/gin в postgres 8.3 в сравнении с предыдущими
0
Заканчиваем - собирать вопросы :-)
Осталось 2 недели до PHPConf
Осталось 2 недели до PHPConf
0
Sign up to leave a comment.
Вопросы авторам PHP на PHPConf 2008 29-30мая в Москве