Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 135
"P.S. Чур вопрос когда будет goto в PHP не предлагать.."
Уже анонсирован? 8)
Уже анонсирован? 8)
- Когда наведут порядок в названиях функций?
Каких конкретно функций?
Ну это из разряда холивара вопрос.
Я имею ввиду неразбериху с именованием.
Например функции для работы с массивами начинаются на array_ но функция sort() почемуто не начинается.
Тоже самое касается строк. Например есть пачка функций начинающхся с str а есть такие которые начинаются на str_, и ещё есть такие которые без префиксов.
Не скажу что это критично, но было бы интуитивно понятнее если бы был какойто стандарт. Ну и вообще -стандарты это хорошо. Особенно это касается именования функций.
Я имею ввиду неразбериху с именованием.
Например функции для работы с массивами начинаются на array_ но функция sort() почемуто не начинается.
Тоже самое касается строк. Например есть пачка функций начинающхся с str а есть такие которые начинаются на str_, и ещё есть такие которые без префиксов.
Не скажу что это критично, но было бы интуитивно понятнее если бы был какойто стандарт. Ну и вообще -стандарты это хорошо. Особенно это касается именования функций.
И разнесут их по классам, превратив в методы.
— Назовите любимый трюк/необычное использование какой-то функции, которое вы когда либо видели.
— Будет ли множественное наследование наконец взято из зенд-ядра и добавлено в сам PHP?
— Когда наконец разберутся с __CLASS__? Нет ли идеи сделать вместо неё две функции: одну, в которой возвращается класс, в которой метод описан, и вторую, в которой возвращается реальный тип объекта? Если верить сообщениям тут, то поведение функции get_class, схожей по функционалу нестабильно, т.е. меняется от версии к версии, если верить комментам к странице.
— Будет ли множественное наследование наконец взято из зенд-ядра и добавлено в сам PHP?
— Когда наконец разберутся с __CLASS__? Нет ли идеи сделать вместо неё две функции: одну, в которой возвращается класс, в которой метод описан, и вторую, в которой возвращается реальный тип объекта? Если верить сообщениям тут, то поведение функции get_class, схожей по функционалу нестабильно, т.е. меняется от версии к версии, если верить комментам к странице.
исходя из описания php6 соответственно вопрос - синтаксис php аккуратно близится к синтаксису перла?
когда можно будет писать такое?
element4 = getSmthList()[3]
element4 = getSmthList()[3]
скорее всего никогда. вот сдесь велась дискуссия на эту тему: http://news.php.net/php.internals/start/… (Array access on function returns)
А зачем? Чтобы все не было слишком просто? =]
Просто мне не понятны причины, по которым не работает.
getSmthList() - это массив, но почему-то не могу с него взять значение - это странно.
getSmthList() - это массив, но почему-то не могу с него взять значение - это странно.
Логически, возможно, Вы правы, но вот практически, это бережет кодеров от
$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 раза.
Т.е. либо получаем весь массив, либо не даем функции отдавать массив. Это удобно и практично, а если нужна логика надо использовать Си или производные от него ;-)
что выведет на экран следующая конструкция?:
$arr = false;
echo count($arr);
$arr = false;
echo count($arr);
1
согласитесь что было бы логичнее если бы возвращало 0.
Функция count() применима для массивов. А так как в языке слабая типизация, то $arr автоматически преобразовывается к массиву {0=>false}. В нем 1 элемент, вот и возвращается 1. Все верно.
ужасти. 0 будет логичнее
Тогда будет куча труднонаходимых ошибок. Данным кодом я хочу узнать количество элементов $arr, а какие у него значения — совсем другое дело. Логично возвращать 0 — когда значение $arr NULL или array(), так сейчас и есть.
Так это ведь не массив.
На мой взгляд, это тоже ведёт к появлению труднонаходимых ошибок.
Думаю, следует выводить нотис или стрикт при передаче count не массива и не объекта. Как считаете?
На мой взгляд, это тоже ведёт к появлению труднонаходимых ошибок.
Думаю, следует выводить нотис или стрикт при передаче count не массива и не объекта. Как считаете?
Строка - это массив. Элементы такого массива - символы строки. И это как раз очень облегчает жизнь =)
Если вызвать $arr[1], где $arr = 'hello', мы получим 'e', т.е. строку можно с натяжкой назвать массивом, где элементы - символы. Хотя в данном случае, строка - это массив с одним элементом.
А вот это уже часто помогает не заморачивать себя проверками строка это или массив, при отсутствии жесткой типизации.
А вот это уже часто помогает не заморачивать себя проверками строка это или массив, при отсутствии жесткой типизации.
Строка очень похожа на массив.
Но для строки вместо count() есть strlen().
Но для строки вместо count() есть strlen().
а что вас удивляет? так может поможет?
$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»…
лично я
хм.. откуда тут "лично я"... :) ну ладно, лично я люблю и php и python и бесконечно восторгаюсь гениальностью, усердием и трудолюбивостью создателей этих языков
Насчет гениальности создателей PHP я бы поспорил. Многовато косяков для языка с 13-летней историей.
ну,создайте свой язык программирования. и давайте не будем... каких косяков?
Чисто наскидку:
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.
ваша конструкция приводит $arr к типу array а потом выводит его.
видимо по такому же алгоритму и работает count().
но не кажется ли вам что было бы логичнее вернуть 0 или false если $arr не массив?
видимо по такому же алгоритму и работает count().
но не кажется ли вам что было бы логичнее вернуть 0 или false если $arr не массив?
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????
1) Когда будет нормальная работа с MSSQL
2) Будет ли создаваться БД SQL специально для PHP
2) Будет ли создаваться БД SQL специально для PHP
2) Будет ли создаваться БД SQL специально для PHP
SQLite?
SQLite?
"Когда будет нормальная работа с MSSQL"
Уже.
Уже.
А ссылки можно на доки?
Вероятно, речь о Microsoft SQL Server 2005 Driver for PHP.
да уже есть нормальный, а также у microsoft c zend есть договорености, о совместной разработке драйвера.
очень хочется узнать о "настоящей" многопоточности в PHP.
zend engine и есть вирт.машина
если хочетцо "пощупать поближе" то: http://ru2.php.net/runkit
если хочетцо "пощупать поближе" то: http://ru2.php.net/runkit
почему нет нормального корного фриварного компилятора в байт код с последующим использованием этого байт-кода?
Потому что любой тогда сможет написать свой энкодер и никто не будет покупать зендовский за ~1000 баксов...
Потому что Зенду невыгодно )
Будет ли когда нибудь строгое типизирование (список параметров и тип возвращаемого результата), полиморфизм.
PS: ведется ли оптимизация самого PHP, хотя это может решится, если будет сделано что-то типа байткода в Java, возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
PS: ведется ли оптимизация самого PHP, хотя это может решится, если будет сделано что-то типа байткода в Java, возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
>Будет ли когда нибудь строгое типизирование (список параметров и тип возвращаемого результата), полиморфизм.
Строгое типизирование уже есть для массива, для остальных типов - противоречит основным идеям РНР.
Полиморфизм - тоже.
>возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
Zend Encoder, Zend Optimizer, eAccelerator и т.д. не подходят?
Строгое типизирование уже есть для массива, для остальных типов - противоречит основным идеям РНР.
Полиморфизм - тоже.
>возможно сделать так, что бы можно было использовать и текстовый формат (как сейчас), так и компилить код
Zend Encoder, Zend Optimizer, eAccelerator и т.д. не подходят?
компиляторы очень дорогие
и не стандартизированы совсем
Не только для массивов, но и для объектов. Нет для простых типов, таких как int, string и т.д....
> Zend Encoder, Zend Optimizer, eAccelerator и т.д. не подходят
Это не совсем то, чего хотелось бы. Например на локальной машине я буду использовать код в текстовом виде, а на продакшн мне бы хотелось не ставить доп. програмы, а скомпилить весь сайт и залить. Это прирост в скорости работы и без разных дополнений. ИМХО это было бы удобно
Это не совсем то, чего хотелось бы. Например на локальной машине я буду использовать код в текстовом виде, а на продакшн мне бы хотелось не ставить доп. програмы, а скомпилить весь сайт и залить. Это прирост в скорости работы и без разных дополнений. ИМХО это было бы удобно
а разве полиморфизм в PHP отсуствует? Абстрактные классы, интерфейсы.
на сколько я знаю я не могу написать draw(Cicrle $c) {...} и draw(Line $l) в одном и том-же класе. Конечно, это ограничение обойти можноЮ но это костыли - не лучше ли сделать это на уровне ядра )
по поводу строгого типизирования - не могу сказать как это отразится на скорости, но может можно объединить оба подхода? во многих ситуациях типизирование полезно, но как я уже сказал - возможно это сильно отразится на скорости, а если так - то не надо ), хотя оптимизаторы байт-кода могут это хорошо оптимизировать.
по поводу строгого типизирования - не могу сказать как это отразится на скорости, но может можно объединить оба подхода? во многих ситуациях типизирование полезно, но как я уже сказал - возможно это сильно отразится на скорости, а если так - то не надо ), хотя оптимизаторы байт-кода могут это хорошо оптимизировать.
можешь.
если Circle и Line наследники одного родителя Figure, то function draw(Figure $fig); очень даже работает
если Circle и Line наследники одного родителя Figure, то function draw(Figure $fig); очень даже работает
в PHP типы int, float, string являются классами такими же как и stdObject, Array (то есть не атомарные как в С) и мне тоже вот не понятно, почему нельзя сделать строгую типизацию.
>ограничение обойти можноЮ но это костыли
Это не костыли, а просто "не так, как вы привыкли". Если, конечно, мы думаем об одном и том же способе применения полиморфизма.
Быть может, код, предлагаемый вами, красивее (хотя это тоже спорно). Но говорить, что PHP не поддерживает полиморфизм - глупо.
Строгое типизирование. Зачем? Это РНР, а не С. В РНР есть множество функций приведения типов, использование которых очень удобно.
Это не костыли, а просто "не так, как вы привыкли". Если, конечно, мы думаем об одном и том же способе применения полиморфизма.
Быть может, код, предлагаемый вами, красивее (хотя это тоже спорно). Но говорить, что PHP не поддерживает полиморфизм - глупо.
Строгое типизирование. Зачем? Это РНР, а не С. В РНР есть множество функций приведения типов, использование которых очень удобно.
Это лишний код - определение типа. Если этот код на C - он быстрее чем вызов ф-ции на PHP
Может я ошибаюсь, но draw(Figure $fig) а не draw(Cicrle $c) {...} и draw(Line $l) {...} - это не полиморфизм
Полиморфизм, как и остальные принципы и паттерны ООП, в большей степени зависят от программиста, и в меньшей - от языка.
В сторону РНР4 можно плюнуть за то, что он предельно слабо поддерживает ООП, с этим я согласен. Но РНР5 реализует основные принципы ООП, это главное. При этом можно смело сказать, что РНР - не на 100% ОО-язык, как C++ и Java, и требовать от него повторения каждой возможности этих языков нельзя. Каждый язык своеобразен, иначе их называли бы одинаково :)
"Не полиморфизм" - это Code Monkey вместо программиста или паскаль вместо языка.
В сторону РНР4 можно плюнуть за то, что он предельно слабо поддерживает ООП, с этим я согласен. Но РНР5 реализует основные принципы ООП, это главное. При этом можно смело сказать, что РНР - не на 100% ОО-язык, как C++ и Java, и требовать от него повторения каждой возможности этих языков нельзя. Каждый язык своеобразен, иначе их называли бы одинаково :)
"Не полиморфизм" - это Code Monkey вместо программиста или паскаль вместо языка.
С каких пор Java и C++ являются 100% ОО-языками? Имхо, единственный толковый 100% ОО-язык —
это Smalltalk. Все остальное - вариации на тему.
И, кстати, что вы лично имеете против паскаля? Уточню: против Borland Pascal? ;-)
это Smalltalk. Все остальное - вариации на тему.
И, кстати, что вы лично имеете против паскаля? Уточню: против Borland Pascal? ;-)
Согласен, несколько ошибся :)
Но это дела не меняет.
Ну, паскаль я не люблю ещё с учёбы - личная взаимная неприязнь :)
Для понимания основ программирования - самое то. Но полиморфизма на нём я и представить не могу :)
Но это дела не меняет.
Ну, паскаль я не люблю ещё с учёбы - личная взаимная неприязнь :)
Для понимания основ программирования - самое то. Но полиморфизма на нём я и представить не могу :)
Возможно я Вас удивлю, но паскаль (Borland Pascal) очень даже позволяет делать полиморфизм, потому что полиморфизм - основа основ ООП, наряду с инкапсуляцией и наследованием. Если рассматривать дотошно, то некоторые вещи в BP реализованы удачнее, чем в C++. Видимо нелюбовь к паскалю у Вас сложилась из-за его морального устаревания к моменту, когда вы стали его изучать. А зря.
Ошибаетесь. Полиморфизм как раз таки использовать draw(Figure $fig). То, что вы подразумеваете под полиморфизмом - называется перегрузка методов :)
раз уж вопрос в деньгах и компилятор из области анриал, то какие механизмы ускорения обработки и опримизации кода будут добавлены?
Может добавить поддержку чего-нибудь наподобие:
Реализовать это возможно... тот же самый "include" только в теле документа.
PHP от этого не пострадает, разработчики ж спасибо скажут. Нужно идти на шаг вперёд, пока кто-нибудь не реализовал (наверное) подобное .
Реализовать это возможно... тот же самый "include" только в теле документа.
PHP от этого не пострадает, разработчики ж спасибо скажут. Нужно идти на шаг вперёд, пока кто-нибудь не реализовал (наверное) подобное .
Имелось ввиду:
Глюк какой то... сорри - смотрим выше видим следующее:
<?perl ... ?>
<?ruby ... ?>
<?python ... ?>
<?perl ... ?>
<?ruby ... ?>
<?python ... ?>
Нифига себе!!! А зачем такое?
Типа страничка HTML, в которую встроен код PHP, в который встроен код Ruby???
Связка HTML+PHP в одном флаконе (в одном файле) уже породила миллионы быдлокодеров и перлы индийского кода, а Вы хотите еще усугубить эту ситуацию???
Типа страничка HTML, в которую встроен код PHP, в который встроен код Ruby???
Связка HTML+PHP в одном флаконе (в одном файле) уже породила миллионы быдлокодеров и перлы индийского кода, а Вы хотите еще усугубить эту ситуацию???
Не так: 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");
?>
И что? Да это удобно, но не всем и не во всём :)
Подумайте, что было бы если работала вышеприведённая связка, думайте не в сторону "быдлокодеров" в другую - ибо писать можно хорошо или просто ужастно на любых языках программирования.
Да, но, извините, зачем???
Зачем писать проект на 3-х разных языках???
Ведь это же соблазн захламления кода.
Пока у Вас есть возможность, но она неудобна, вы будете вынуждены
использовать ее редко и, как следствие, обдуманно, продумывая архитектуру приложения.
Даже если у Вас в команде программисты с разными языками Вы вынуждены будете заставлять их писать нормальные модули, а потом использовать их, а не тупо лепить вставки кода на разных языках...
Зачем писать проект на 3-х разных языках???
Ведь это же соблазн захламления кода.
Пока у Вас есть возможность, но она неудобна, вы будете вынуждены
использовать ее редко и, как следствие, обдуманно, продумывая архитектуру приложения.
Даже если у Вас в команде программисты с разными языками Вы вынуждены будете заставлять их писать нормальные модули, а потом использовать их, а не тупо лепить вставки кода на разных языках...
Попытаюсь объяснить кратко.
Я лично пишу на 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, не знаю. Реализованное в одном языке программирования не всегда реализовано в другом. Таким вот образом возможно было бы частично решить проблему.
"лично для меня" если для себя то да.
а клиенту как такое "фтюхивать"?
а клиенту как такое "фтюхивать"?
Разве клиент (заказчик) прописывает в договоре (ТЗ), что ему выдай всё на PHP пожалуйста?
да канечно, не знаю как, но у нас в договоре есть пункт "технические требования".
и для командной разработки этот венегрет просто не годится. (:
и для командной разработки этот венегрет просто не годится. (:
Согласен - слишком сложно для клиента.
Но если вернуться к вопросам авторам 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";
?>
бугага, ну если сильно хочется - модуль для апача написать не сложно. (: думаю это уже ктото написал (:
Когда будут неймспейсы?!
Когда мы получим возможность разрабатывать на PHP полноценные серверы приложений а-ля Tomcat/Java servlets вместо одноразовых "скриптов"?
Имеет ли смысл перенести функционал некоторых паттернов (например Singleton) в php?
хотелось бы, чтобы при объявлении функции можно было указать типы входных аргументов..
если аргумент пришел другого типа - сразу warning
к примеру:
myfunction(string $a, array $b, integer $c, object $d){......}
если аргумент пришел другого типа - сразу warning
к примеру:
myfunction(string $a, array $b, integer $c, object $d){......}
Не думаю, что это призыв к переходу на строгую типизацию в PHP, а для аргументов функций и методов это в отдельных случаях действительно могло бы быть полезно.
Есть способ это сымитировать, достаточно простой и удобный:
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.
когда появится кастинг !?
не преобразование (int)'123asd' (->123), а просто как подсказка IDE(и компилятору!?) с каким "типом" я собираюсь в данный момент работать.
хочется удобства в ситуациях вроде такой:
$customClassInstance = (CustomClass)unserialize($str);
и тут-же в IDE в автокомплите видеть методы CustomClass, а не «фигпоймчего»...
не преобразование (int)'123asd' (->123), а просто как подсказка IDE(и компилятору!?) с каким "типом" я собираюсь в данный момент работать.
хочется удобства в ситуациях вроде такой:
$customClassInstance = (CustomClass)unserialize($str);
и тут-же в IDE в автокомплите видеть методы CustomClass, а не «фигпоймчего»...
На всякий случай озвучу в качестве самостоятельного вопроса.
Планируется ли полный переход на ООП на уровне встроенных функций путём создания систематизированной совокупности стандартных классов и превращения встроенных функций в методы этих классов? Например, все функции с префиксом array_ этого префикса лишатся и станут методами класса array. Про 5.3 не говорю, но хотя бы в шестёрке или, ммм… будущих версиях.
И попутно: как насчёт перехода на более традиционный ныне «верблюжий» синтаксис (подобно используемому в JavaScript или, например, при работе с DOM-расширением в PHP5)? Например, применительно к потенциальному объекту array метод мог бы называться walkRecursive вместо walk_recursive.
Спасибо.
Планируется ли полный переход на ООП на уровне встроенных функций путём создания систематизированной совокупности стандартных классов и превращения встроенных функций в методы этих классов? Например, все функции с префиксом array_ этого префикса лишатся и станут методами класса array. Про 5.3 не говорю, но хотя бы в шестёрке или, ммм… будущих версиях.
И попутно: как насчёт перехода на более традиционный ныне «верблюжий» синтаксис (подобно используемому в JavaScript или, например, при работе с DOM-расширением в PHP5)? Например, применительно к потенциальному объекту array метод мог бы называться walkRecursive вместо walk_recursive.
Спасибо.
Давайте их сначала отберем. Я путаюсь в этой простыне :-(
P.S. Программа опбуликована сегодня..
http://www.phpconf.ru/programm/
P.S. Программа опбуликована сегодня..
http://www.phpconf.ru/programm/
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?
Вот, пожалуй, всё. На пока что.
Когда будет реализовано (и будет ли):
class A {
private $obj = new Object();
}
вместо того, что бы в кострукторе создавать объект.
class A {
private $obj = new Object();
}
вместо того, что бы в кострукторе создавать объект.
SPHINX: как растет производительность индексов типа gist/gin в postgres 8.3 в сравнении с предыдущими
Заканчиваем - собирать вопросы :-)
Осталось 2 недели до PHPConf
Осталось 2 недели до PHPConf
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вопросы авторам PHP на PHPConf 2008 29-30мая в Москве