Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 329
АААА! Лейблы… Зачем? Теперь что бы разобрать код начинающего кодера с лейблами прийдеться выпивать вдвое больше.
Но с лейблами станет еще хуже. Не могу понять, зачем они вводят лейблы?
Видимо хотят превратить РНР в BASIC. Великолепно, блин.
Ну смотрите, вводят нэймспейсы, вводят лямбда функции, великолепно. И тут бац, и лейблы. Просто интересно что двигало логикой тех людей которые добавляли лейблы. Может конечно есть разумное объяснение.
Можно подумать, что goto в одном только Basic и есть. Вспомните Си что ли. Его никто Бейсиком не называет.
Более того, когда глубина рекурсии на платформе сильно ограничена, остаётся только лишь тот самый goto. :)
глубина вызова, я хотел сказать. необязательно рекурсии.
Меня всегда радуют разговоры о том что GOTO это плохо. Ведь вызов процедуры (функции) это и есть GOTO + объявление параметров + GOTO обратно. Только в случае с функцией мы пишем адреса в стек. И чем глубже рекурсия, тем больше растёт стек. Это удобно на небольшом уровне вложенности, но не надо забывать что овёс нынче дорог. При большом уровне вложенности лучше брать GOTO на свою совесть.
> При большом уровне вложенности лучше брать GOTO на свою совесть.
Да, и нафиг вообще абстракции нужны? Давайте делать возьмем побольше работы машины на себя.
А если серьезно, то ключевое слово тут это оптимизация хвостовых вызовов.
Да, и нафиг вообще абстракции нужны? Давайте делать возьмем побольше работы машины на себя.
А если серьезно, то ключевое слово тут это оптимизация хвостовых вызовов.
Никто не говорит, что goto — это безусловно плохо. Есть много задач, в которых применение goto дает вполне весомый выигрыш. Например, конечные автоматы.
Другое дело, что, как правильно заметил товарищ chiaroscuro, программирующая часть человечества уже давно придумала более высокоуровневые абстракции чем «метки+goto». Например, вызов функции с оптимизацией хвостовой рекурсии.
Подобная абстракция позволяет заменять циклы на рекурсию, а условные или безусловные переходы на вызов функции. И конечный код получается оптимизирован ничуть не хуже, чем при использовании goto, но значительно выигравает в легкости чтения и понимания.
Другое дело, что, как правильно заметил товарищ chiaroscuro, программирующая часть человечества уже давно придумала более высокоуровневые абстракции чем «метки+goto». Например, вызов функции с оптимизацией хвостовой рекурсии.
Подобная абстракция позволяет заменять циклы на рекурсию, а условные или безусловные переходы на вызов функции. И конечный код получается оптимизирован ничуть не хуже, чем при использовании goto, но значительно выигравает в легкости чтения и понимания.
помнится в ассемблере что-то подобное было, только в русской универовской транскрипции это меткой называлось
Ну, если мне не изменяет память…
В ассемблерах есть команды перехода на адрес и/или перехода по смещению. В ассемблере x86 есть FAR JUMP (на полный адрес с сегментом), NEAR JUMP (длинное смещение, знаковое слово) и SHORT JUMP (короткое смещение, байт со знаком).
Чтобы при написании программы, не считать команды вручную и не делать смещение на адрес, были придуманы метки (labels). Ставишь JMP Out, а компилятор сам вычисляет где находится Out и какой сделать JMP.
В ассемблерах есть команды перехода на адрес и/или перехода по смещению. В ассемблере x86 есть FAR JUMP (на полный адрес с сегментом), NEAR JUMP (длинное смещение, знаковое слово) и SHORT JUMP (короткое смещение, байт со знаком).
Чтобы при написании программы, не считать команды вручную и не делать смещение на адрес, были придуманы метки (labels). Ставишь JMP Out, а компилятор сам вычисляет где находится Out и какой сделать JMP.
Думаю что не стоит путать язык и стандарт кодирования. Не нравится — не пользуйся. Уверен есть ситуации когда это будет к месту.
Хз, товарищи, когда я лет 5-6 назад делал свой темплейтный движок, лейблов мне очень не хватало для существенного увеличения скорости;
каждый пхпшник считает своим долгом написать темплейтный движок и цмс
А Вы, как собачка, стойку делаете? ПЯТЬ-ШЕСТЬ ЛЕТ назад (внимательно, пожалуйста, 2003-2004 год) — тогда был только смарти, а смарти меня не устраивал.
К тому же, а что, собственно, еще писать на пхп, кроме как темплейтные движки и цмс?
К тому же, а что, собственно, еще писать на пхп, кроме как темплейтные движки и цмс?
Сейчас в моде фреймворки
Что-ж вы так к GOTO цепляетесь? :)
Goto есть в очень многих языках, кроме бейсика (C#, тот же Delphi, насчет C не знаю но должен быть тоже)
Чем вам лишний функционал языка мешает? Или все сразу начнут использовать GOTO вместо вызова методов? Пока-что такого не происходило вроде-бы и врядли произойдет.
У GOTO тоже есть свое применение, особенно когда не хватает размера стека. Просто каждому оператору свое место и время.
Goto есть в очень многих языках, кроме бейсика (C#, тот же Delphi, насчет C не знаю но должен быть тоже)
Чем вам лишний функционал языка мешает? Или все сразу начнут использовать GOTO вместо вызова методов? Пока-что такого не происходило вроде-бы и врядли произойдет.
У GOTO тоже есть свое применение, особенно когда не хватает размера стека. Просто каждому оператору свое место и время.
Между прочим, все это обсуждалось и свое мнение можно было высказать в открытых списках рассылки, которые читают и в которые пишут разработчики — еще до того, как это было реализовано. Каждый сам кузнец своего [не]счастья
Я когда-то сталкивался с такой задачей.
— Начало цитаты.
Да, Вы правы, я без зазрения совести использую операторы безусловного перехода! И это после работы Дейкстры, заклеймившей goto!!! Как можно посягать на каноны программирования, когда в современных языках этот оператор просто не существует!!! А ведь Вы еще не видели программной реализации диаграмм, используемых в синтаксическом анализаторе!!! Я не собираюсь с пеной у рта отстаивать используемое решение, но робко мотивировать его все же попробую.
Во-первых, основным документом, по которому разрабатываются программные модули, является диаграмма Вирта, которая, в общем случае является неструктурированным графом. А такие графы невозможно представить без goto, если только не осуществить соответствующие преобразования. Применение же этих преобразований может снизить наглядность исходных диаграмм, привести к их избыточности, что ведет к соответствующему «захламлению» и формируемого кода. Тогда проще сразу отказаться от диаграмм Вирта и перейти на РБНФ. Именно неструктурированные диаграммы Вирта диктуют мне ранее описанную регулярную схему моделирования каждой ее отдельной связи.
Во-вторых, используя данный подход, можно, с помощью экранного редактора, достаточно быстро набирать фрагменты новых правил, перенося отдельные связи из ранее набранных диаграмм. Особенно удобно такое редактирование при написании синтаксического анализатора.
— конец цитаты.
Источник:
softcraft.ru/translat/lect/t05-02.shtml
— Начало цитаты.
Да, Вы правы, я без зазрения совести использую операторы безусловного перехода! И это после работы Дейкстры, заклеймившей goto!!! Как можно посягать на каноны программирования, когда в современных языках этот оператор просто не существует!!! А ведь Вы еще не видели программной реализации диаграмм, используемых в синтаксическом анализаторе!!! Я не собираюсь с пеной у рта отстаивать используемое решение, но робко мотивировать его все же попробую.
Во-первых, основным документом, по которому разрабатываются программные модули, является диаграмма Вирта, которая, в общем случае является неструктурированным графом. А такие графы невозможно представить без goto, если только не осуществить соответствующие преобразования. Применение же этих преобразований может снизить наглядность исходных диаграмм, привести к их избыточности, что ведет к соответствующему «захламлению» и формируемого кода. Тогда проще сразу отказаться от диаграмм Вирта и перейти на РБНФ. Именно неструктурированные диаграммы Вирта диктуют мне ранее описанную регулярную схему моделирования каждой ее отдельной связи.
Во-вторых, используя данный подход, можно, с помощью экранного редактора, достаточно быстро набирать фрагменты новых правил, перенося отдельные связи из ранее набранных диаграмм. Особенно удобно такое редактирование при написании синтаксического анализатора.
— конец цитаты.
Источник:
softcraft.ru/translat/lect/t05-02.shtml
я отношусь к goto, как к нежелательному, но допустимому, тоесть нужно стараться обходиться без него, но в меру.
Вот блин, я расстроен лейблами. Их если и можно вводить — то только как недефолтную опцию. А чтобы включить данную опцию интерпретаторы — длинные многоуровневые грабли, чтобы начинающий кодер только лишь мечтал, но не включал ее.
Все хорошо, но вот лейблы — это лишнее имхо.
Все хорошо, но вот лейблы — это лишнее имхо.
Вкусностей много, а препятствием как всегда будут хостеры.
Честно говоря, для меня остается загадкой, как будут разрабатываться дальше фреймворки типа Zend Framework и symfony. Вести 2 ветки разработки весьма непросто, но и вкусности хочется реализовать (namespaces в Zend Framework были бы весьма кстати) и пролетать мимо хостинга не хочется.
Честно говоря, для меня остается загадкой, как будут разрабатываться дальше фреймворки типа Zend Framework и symfony. Вести 2 ветки разработки весьма непросто, но и вкусности хочется реализовать (namespaces в Zend Framework были бы весьма кстати) и пролетать мимо хостинга не хочется.
Мне думается что хостеры быстро поставят 5.3, это снизит нагрузку. Да и всё больше людей пользуются VPS.
Поправьте меня, если я не прав, но по-моему в этом случае полетят все сайты, у которых register_globals = on. Боюсь, что таких еще очень много…
Поправляю.
register_globals уберут из PHP6, в 5.3 её еще можно сделать = on ;)
Но я бы давно убрал register_globals и magic_quotes — уж больно они ужасны
Но я бы давно убрал register_globals и magic_quotes — уж больно они ужасны
А смысл убирать? По дефолту они отключены, а если надо быстро завести древний скрипт — очень полезно.
Уже прошло много лет, чтобы можно было перенести старые скрипты. register_globals, если память не изменяет, еще на 4.2 не рекомендовался. Глобалс — большая дыра безопасности, и самое страшное, что и сейчас так пишет много народа.
Проблемы индейцев шерифа не…
Кто хочет наиндусить, тот всегда найдет способ.
extract($_REQUEST,EXTR_SKIP);
Это еще хорошо если про EXTR_SKIP будут знать.
Кто хочет наиндусить, тот всегда найдет способ.
extract($_REQUEST,EXTR_SKIP);
Это еще хорошо если про EXTR_SKIP будут знать.
Все будет как и раньше. Например у symfony и так высокие требования к версии ПХП. Думаю со 2-ой версии они уже перепрыгнут на 5.3.
В Zend Framework разработчики давно готовятся к новой версии php, и уж у кого-у кого, а у ZF не будет с этим проблем. Более того, в новых версиях ZF эти новые возможности будут активно использоваться, в отличии от других фреймворков которые до сих пор топчутся с php4.
Нововведение 4 мне, например, кажется полезным. С оптимизационной точки зрения. Хотя, фиг его знает, как оно реализовано, возможно значение вычисляется дважды %))
я тоже считаю её полезной. Часто использую. Только не понял, в 5.3 можно будет убирать false-часть? Хотя это конечн не важно.
Можно будет убирать (опускать) наоборот true-часть. Если убирать false-часть, то зачем тогда вообще тернарник? :)
ну не знаю. Мне кажется удобно использовать такую конструкцию, когда, например, нужно тег div вывести, но неизвестно, следует ли подставлять имя css-класса:
Может не сильно, но все же короче записать без " :'' " в данном случае.
$output = '<div class="informer'.($class?' '.$class:'').'">';
* This source code was highlighted with Source Code Highlighter.Может не сильно, но все же короче записать без " :'' " в данном случае.
Разделитель нэймспейсов решили сделать человеческий? А то, ходили слухи, что будет два слеша…
::
Да уж давно как нет. Используется бэкслеш (\).
Да, будем писать
use aa\b\ccc;
и
$a = new ddd\eee\ccc(1);
ИМХО разделитель \ вместо :: — все-таки изврат.
Но с php.net/namespaces не поспоришь…
use aa\b\ccc;
и
$a = new ddd\eee\ccc(1);
ИМХО разделитель \ вместо :: — все-таки изврат.
Но с php.net/namespaces не поспоришь…
Да, полный изврат.
В действительности нельзя исключать, что в будущем механизм разбора кода усовершенствуют (если мне не изменяет память, именно слабость текущей реализации парсера явилась главной причиной отказа от двоеточий) и помимо слэшей добавят и поддержку двойных двоеточий применительно к пространствам имён.
Ну это будет ИМХО еще больший изврат — 2 синтаксиса для абсолютно одного и того же. Так что я бы лично не рассчитывал на то, что мы в ближайшие 5-10 лет увидим :: вместо \…
Да и бог с ним, с этим «::». Дело привычки. Мне вот «@» (декоратор) казался в Python ужасным. Теперь привык.
Бывают решения временные. Парсер слаб — сделали слэши; усовершенствовали парсер — сделали по-человечески, иное пометили как нерекомендуемое и со временем упразднили. Логики не лишено, хотя, конечно, вероятность реализации мала.
Интересно, кто-нибудь и правда верит в версию слабого парсера?
Наверное, только идиоты. Если не путаю, парсер там генерируется YACC (или flex?)
(Безотносительно парсера в пхп) Вы думаете, что парсер, сгенерированный YACC-ом, не может быть слабым? :)
Простите, а относительно чего тогда? Мы тут про разделение неймспейсов и, якобы, слабый парсер. Я, зная синтаксис YACC, утверждаю, что сделать какой угодно разделитель не составляет никаких, я повторяю, никаких проблем.
Под «безотносительно пхп» имелось в виду, что я говорю не про именно парсер пхп, а про «абстрактный сферический парсер в вакууме» на YACC. И да, его можно написать сколь угодно корявым и слабым. Ровно это имелось в виду. То есть утверждение «парсер написан на YACC, поэтому он не может быть слабым» неверно.
Простите, Вы вообще имеете представление, о чем конкретно Вы говорите? YACC позволяет описывать синтаксис языка, в стиле:
top_statement:
statement
| function_declaration_statement { zend_do_early_binding(TSRMLS_C); }
| class_declaration_statement { zend_do_early_binding(TSRMLS_C); }
| T_HALT_COMPILER '(' ')' ';' { zend_do_halt_compiler_register(TSRMLS_C); YYACCEPT; }
;
и генерировать C-парсер на этой основе. Сделать синтаксис сильным или слабым по-моему невозможно (ибо субъективно), зато описать свой язык так, как хочешь, без заковык и переподвыподвертов можно легко и непринужденно.
top_statement:
statement
| function_declaration_statement { zend_do_early_binding(TSRMLS_C); }
| class_declaration_statement { zend_do_early_binding(TSRMLS_C); }
| T_HALT_COMPILER '(' ')' ';' { zend_do_halt_compiler_register(TSRMLS_C); YYACCEPT; }
;
и генерировать C-парсер на этой основе. Сделать синтаксис сильным или слабым по-моему невозможно (ибо субъективно), зато описать свой язык так, как хочешь, без заковык и переподвыподвертов можно легко и непринужденно.
> Простите, Вы вообще имеете представление, о чем конкретно Вы говорите?
Я — да. Вы — похоже, нет.
Вы утверждаете, что на YACC-е нельзя плохо описать синтаксис? Вы верите в программы с багами? Вы верите в неверно спроектированные архитектуры? Вы когда-нибудь видели плохой код?
Я — да. Вы — похоже, нет.
Вы утверждаете, что на YACC-е нельзя плохо описать синтаксис? Вы верите в программы с багами? Вы верите в неверно спроектированные архитектуры? Вы когда-нибудь видели плохой код?
Если вы не очень толстый тролль (в чем я перестаю сомневаться), перечитайте вот этот комментарий — habrahabr.ru/blogs/php/59876/#comment_1629597 и объясните, как это соотносится с тем, что впариваете мне Вы?
Если же тролль — аривидерчи.
Если же тролль — аривидерчи.
Тролль здесь, похоже вы, т.к. совершенно не читаете на что отвечаете и не утруждаете себя подумать перед ответом.
До свидания.
До свидания.
Благодарю за минус в карму, лишить меня возможности писать посты и делиться своими знаниями с такими гениями, как Вы, избавляет от мучительного выбора.
Save the planet, kill yourself
Save the planet, kill yourself
А разве от двоиных двоеточий отказались не из-за неоднозначности?
a::b::c — это что? вызов статического метода «с» из класса «b», пространства «а» или вызов функции «с» из пространства «а::b»?
a::b::c — это что? вызов статического метода «с» из класса «b», пространства «а» или вызов функции «с» из пространства «а::b»?
Любые неоднозначности разрешаются единожды принимаемым соглашением.
Какое соглашение вы приняли бы в этом случае?
Можно принять, что приоритет пространства имён выше приоритета чего-либо иного. Если пространство имён не найдено, ищется класс.
Примерно так всё и сделали бы, если бы этот синтаксис приняли бы. Но хорошо, что этого не сделали. Так как, если бы я увидел в коде «a::b::c» я не смог бы понять что тут вызывается, не разбираясь с кодом.
Согласен. Хотя на уровне простоты восприятия кода помогло бы (помимо банальной особой подсветки пространств имён в IDE) соглашение именовать пространства имён, например, со строчной буквы — в противоположность классам, имена которых принято начинать с заглавной:
myNs::MyClass::myMethod();Или ещё проще — сделать символ разделения namespace каким-нибудь другим, что и было сделано. Кстати, предлагалось «:::», но, видимо, решили, что это набирать очень долго, да и отличать от «::» его сложнее.
Можно было бы, кстати, просто предварять пространства имён спецсимволом подобно $ у переменных — например, @, это полностью исключило бы неоднозначности:
@myNs::MyClass::myMethod();
Придумывать новый разделитель, по-моему, решение в любом случае менее удачное.
@myNs::MyClass::myMethod();
Придумывать новый разделитель, по-моему, решение в любом случае менее удачное.
Новый по отношению к чему? Пространств в PHP не существовало. Появились и появился для них синтаксис. «\» ничем не лучше и не хуже любого другого значка.
Вот в Виндах обратный слеш — разделитель путей и ничего, много лет, со времён ДОСа все его используют.
Вот в Виндах обратный слеш — разделитель путей и ничего, много лет, со времён ДОСа все его используют.
Новый по отношению к чему?Новый разделитель уровней иерархии программных сущностей. Представьте, что «хлебные крошки» на сайте выглядели бы так:
Главная \ Продукция :: Булочки
только потому, что главная страница сайта функционально отличается от всех остальных страниц.
Вариант
Главная → Продукция → Булочки
лучше просто потому, что единообразнее.
Вот в Виндах обратный слеш — разделитель путей и ничего, много лет, со времён ДОСа все его используют.Несколько отклоняемся от темы, но почему в Windows до сих пор не сделали разделителем фрагментов пути по умолчанию слэши прямые (/), подобно путям в Unix-системах и интернет-адресам — совершенно непостижимо (и это уже при наличии поддержки таких путей в Windows: попробуйте, скажем,
C:/WINDOWS/system32).Главная → Продукция → Булочки
Плохой пример. В PHP возникнет двойственность, я уже писал об этом. В хлебных крошках — нет.
Windows до сих пор не сделали разделителем фрагментов пути по умолчанию слэши прямые (/), подобно путям в Unix-системах и интернет-адресам — совершенно непостижимо (и это уже при наличии поддержки таких путей в Windows: попробуйте, скажем, C:/WINDOWS/system32).Да, я знаю, что она там есть. Ответ в том, что делать прямой слеш разделителем по умолчанию нет никакой необходимости. Это просто символ. Ничем не хуже любого другого символа.
В PHP возникнет двойственность, я уже писал об этом.При использовании спецсимвола для обозначения названия пространства имён (вида @myNs) неоднозначности были бы исключены.
делать прямой слеш разделителем по умолчанию нет никакой необходимости.Необходимости нет, есть целесообразность — единообразие. Вводить в одну и ту же адресную строку интернет-адреса с прямым слэшом, а локальные пути — почему-то с обратным — несколько странно. ;-)
Хороший алгоритм, только для человеческого использования он не удобен.
Концептуально, «class» сам по себе образует пространство имен. Для классов есть чудная арифметика, позволяющая эти пространства имен комбинировать — слово extends все знают?… И главное — эти чудеса живут в языке еще со времен PHP4. =)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
:: уже занят, а жертвовать совместимостью ради неймспесов — идиотизм
100% через пару дней пользования все привыкнут, так-что думаю не стоит делать из мухи слона
100% через пару дней пользования все привыкнут, так-что думаю не стоит делать из мухи слона
Тернарный оператор.?: компактнее, чем отдельный if, и, вероятно, реализован оптимальнее, чем традиционный тернарный оператор, осуществляющий ненужное присваивание переменной самой себе в случае срабатывания true-альтернативы.
Можно использовать без указания true-альтернативы, тогда ей становится само значение.
Однако, в этом я вижу очень мало практического применения.
Не соглашусь. Нововведение в ущерб читаемости кода. Я честно говоря всегда наивно полагал, что оптимизация, исключающая лишнее присваивание, совершается при компиляции кода и для этого не нужен еще один синтаксис. Меня неприятно удивит, если это было не так, и Вы правы.
Повышенная оптимальность — не более чем предположение.
Читаемость не ниже, чем у обычного тернарного оператора, при этом исключается бессмысленное дублирование переменной в коде. Вам же не приходит в голову, что запись
Читаемость не ниже, чем у обычного тернарного оператора, при этом исключается бессмысленное дублирование переменной в коде. Вам же не приходит в голову, что запись
$a = $a + $b — лучше, чем $a += $b. Или приходит? ;-)А по-моему, читаемость только выиграет от ?:
В Perl, например, можно писать
$a = $b || 10;
А теперь и в PHP можно будет:
$a = $b :? 10;
Правда, в Perl можно еще и
$a ||= 10;
а вот в PHP
$a :?= 10 — вроде пока нельзя (а жаль).
Удобен ?: тем, что не нужно дважды повторять одно и то же rvalue (особенно когда это rvalue длинное или представляет, например, вызов функции — вот тут-то в 5.2 без временной переменной вообще не обойтись было).
В Perl, например, можно писать
$a = $b || 10;
А теперь и в PHP можно будет:
$a = $b :? 10;
Правда, в Perl можно еще и
$a ||= 10;
а вот в PHP
$a :?= 10 — вроде пока нельзя (а жаль).
Удобен ?: тем, что не нужно дважды повторять одно и то же rvalue (особенно когда это rvalue длинное или представляет, например, вызов функции — вот тут-то в 5.2 без временной переменной вообще не обойтись было).
$a or $a = 10;
А что вы собрались присваивать вызову функции? O_o
буквально сегодня правил код, хотелось написать что-то типа:
$discount = calcuate_discount($param) >0? calcuate_discount($param): 0;
Естественно делать не стал (т.к. не самая легкая функция вызывалась бы дважды)
Пришлось писать в две строки, тоже не самое читабельное решение.
P.S. Есть субъективные причины почему алгоритм работает именно так и эта проверка нужна.
$discount = calcuate_discount($param) >0? calcuate_discount($param): 0;
Естественно делать не стал (т.к. не самая легкая функция вызывалась бы дважды)
Пришлось писать в две строки, тоже не самое читабельное решение.
P.S. Есть субъективные причины почему алгоритм работает именно так и эта проверка нужна.
if ( ($discount = calcuate_discount($param)) < 0) $discount = 0;
А как там с обратной совместимостью? косяков не будет?
Спасибо, сделал ремарку в начале обзора.
> Особенных проблем обратной совместимости нет, за исключением введения новых зарезервированных слов и других малозначительных моментов.
Мне вот инетересно что будет если определить статический класс (использую эту методику для эмулирования нэймспэйсов), а потом случайно опеределить такой-же неймспейс… ошибка или разделение приоритетов?
Лично я от 5.3 жду не дождусь Late Static Bindings. У меня сейчас в одном месте совершенно аццкая определялка текущего класса с помощью debug_backtrace(), а в других я просто отказался от статических методов, хотя они там очень бы пригодились.
а чем get_class() не угодил?
get_class(self)? o_O
попробуйте вызвать var_dump(get_class()) в контексте унаследованного статического метода. o_O
Видимо речь идет о выполнении внутри статичного метода.
$className = get_class();
$obj = new $className();
$obj->yourFavouriteStaticMethod();
попробуйте. :)
$obj = new $className();
$obj->yourFavouriteStaticMethod();
попробуйте. :)
согласитесь, это костыли
Речь, насколько я понял, была не об этом. А о том, что безумно криво устроено, например, в том же Propel: невозможность в СТАТИЧЕСКОМ методе базового класса определить, для какого из производных классов он вызван. Например:
class Base {
public static function f() { echo что-то-что-дает-имя-класса; }
public function r() {… }
public function call() { self::r(); }
}
class Derive extends Base {
public function r() {… }
}
Base::f(); // хочется увидеть «Base»
Derive::f(); // хочется увидеть «Derive»
Derive::call(); // хочется, чтобы была вызвана Derive::r(), а не Base::r()
Так вот, из-за того, что в 5.2 не существует способа реализовать функцию f(), чтобы она работала, как описано, они создают громадные генераторы кода, которые в основном только и делают, что создают бесконечные статические методы. Более того, делать у себя в программе производные классы почти невозможно — именно из-за отсутствия полиморфности у статических методов как таковой.
class Base {
public static function f() { echo что-то-что-дает-имя-класса; }
public function r() {… }
public function call() { self::r(); }
}
class Derive extends Base {
public function r() {… }
}
Base::f(); // хочется увидеть «Base»
Derive::f(); // хочется увидеть «Derive»
Derive::call(); // хочется, чтобы была вызвана Derive::r(), а не Base::r()
Так вот, из-за того, что в 5.2 не существует способа реализовать функцию f(), чтобы она работала, как описано, они создают громадные генераторы кода, которые в основном только и делают, что создают бесконечные статические методы. Более того, делать у себя в программе производные классы почти невозможно — именно из-за отсутствия полиморфности у статических методов как таковой.
Late Static Binding *именно* про это.
Нет, late static binding — это например возможность обратиться к реализации статического метода, которая будет определена в наследниках.
То, о чем Дима говорит в 5.3 не решено какой либо константой типа __CLASS__, а решено функцией get_called_class(), о которой я на самом деле и говорил в своих примерах, но забыл точное название и то, что она только в 5.3 и появилась.
То, о чем Дима говорит в 5.3 не решено какой либо константой типа __CLASS__, а решено функцией get_called_class(), о которой я на самом деле и говорил в своих примерах, но забыл точное название и то, что она только в 5.3 и появилась.
Late Static Bindings это вообще не возможность. Все проблемы, которые решает LSB расписаны вот тут: ua2.php.net/manual/en/language.oop5.late-static-bindings.php
Решено это не get_called_class'ом, а новой константой static.
Решено это не get_called_class'ом, а новой константой static.
У автора комментария первого уровня и у Димы (функция f()) речь шла именно о том, чтобы получить название класса потомка в статическом, _унаследованном_ методе класса родителя.
и задача как раз в том, чтoбы именно приведённый код или аналогичные ему при вызове B::who() выводил «B», а не «A».
Покажи пожалуйста, как ключевое слово static (а не константа, как ты утверждаешь) при вызове статического метода решит поставленную задачу.
class A {
static function who() {
$className = ''; //тут нужно получить название класса;
echo $className;
}
}
class B extends A {
}
B::who()
* This source code was highlighted with Source Code Highlighter.и задача как раз в том, чтoбы именно приведённый код или аналогичные ему при вызове B::who() выводил «B», а не «A».
Покажи пожалуйста, как ключевое слово static (а не константа, как ты утверждаешь) при вызове статического метода решит поставленную задачу.
Я не утверждаю, что static константа. Ключевое слово, пожалуй, да.
static public function who() {
echo static::whoAmI();
}
static public whoAmI() {
return __CLASS__;
}
static public function who() {
echo static::whoAmI();
}
static public whoAmI() {
return __CLASS__;
}
class A {
static public function who() {
echo static::whoAmI();
}
static public function whoAmI() {
return __CLASS__;
}
}
class B extends A {
}
B::who();
* This source code was highlighted with Source Code Highlighter.с последним релиз кандидатом этот код выводит «А», а ведь ты думал что он будет выводить «B»?
Ну да. Всё я написал-то неверно. Работает нормально, это я ошибся.
<?
class A {
static public function who() {
echo static::whoAmI();
}
static public function whoAmI() {
return __CLASS__;
}
}
class B extends A {
static public function whoAmI() {
return __CLASS__;
}
}
B::who();
<?
class A {
static public function who() {
echo static::whoAmI();
}
static public function whoAmI() {
return __CLASS__;
}
}
class B extends A {
static public function whoAmI() {
return __CLASS__;
}
}
B::who();
В контексте задачи «автора комментария первого уровня» этот код не имеет смысла, так как приходится реализовывать метод whoAmI в наследниках, что реализуемо и в 5.2.8 в лоб.
Вот решение.
class A {
static function who() {
echo get_called_class();
}
}
class B extends A {
}
B::who();
* This source code was highlighted with Source Code Highlighter.Вот решение.
* ", что реализуемо и в 5.2.8 в лоб"
Честно сказать, я не понимаю зачем нам знать имя класса. Для debug'a?
Вот вызов из наследуемого класса неперектытого метода в контексте потомка — этого я и ожидал. Сейчас неактуально, правда уже — на PHP пишу всё меньше.
Вот вызов из наследуемого класса неперектытого метода в контексте потомка — этого я и ожидал. Сейчас неактуально, правда уже — на PHP пишу всё меньше.
Есть масса случаев, когда нужно знать имя класса наследника — из простых паттернов — это реализация абстрактного синглетона, из более сложных ORMы всякие, как минимум файндерам реализованным в виде статических методов единожды нужно знать какая именно модель запрашивается — сейчас это решается кодогенерацией и название класса просто передаётся как аргумент в файндер, в 5.3 будет достаточно в файндере сделать get_called_class()
Мне тоже етого метода нехватает. Ето полезно в абстрактных класах которые вызываются статически, в моем случаи ето абстрактный класс Extention которого наследуют Widget и Module соответственно каждый из них имеет свои параметры.
А пока приходится через debug_backtrace() извлекать.
А пока приходится через debug_backtrace() извлекать.
$className = get_class();
$obj = new $className();
$obj->yourFavouriteStaticMethod();
Ы?
$obj = new $className();
$obj->yourFavouriteStaticMethod();
Ы?
Не путай вызов метода объекта и статический вызов метода класса.
В твоём случае:
1) константа self доступна не будет
2) get_class у неперекрытого метода родителя будет равняются имени родительского класса, а не класса, расширяющего родительский (именно эту проблему решает Late Static Binding)
кстати, get_class можно не использовать, есть константа __CLASS__, вызов функции всегда медленее остальных способов получения информации.
В твоём случае:
1) константа self доступна не будет
2) get_class у неперекрытого метода родителя будет равняются имени родительского класса, а не класса, расширяющего родительский (именно эту проблему решает Late Static Binding)
кстати, get_class можно не использовать, есть константа __CLASS__, вызов функции всегда медленее остальных способов получения информации.
1) ты не прав, self будет доступна
2) я не прав
2) я не прав
поправочка:
2) late static binding не решает эту проблему
2) late static binding не решает эту проблему
Мда. Ты видимо, забыл с кем споришь.
2) late static binding решает вот эту проблему (взято из документации):
<?php
class A {
public static function who() {
echo __CLASS__;
}
public static function test() {
self::who();
}
}
class B extends A {
public static function who() {
echo __CLASS__;
}
}
B::test();
тут вызов B::test() выдаст «A», а хотелось бы — что бы «B».
2) late static binding решает вот эту проблему (взято из документации):
<?php
class A {
public static function who() {
echo __CLASS__;
}
public static function test() {
self::who();
}
}
class B extends A {
public static function who() {
echo __CLASS__;
}
}
B::test();
тут вызов B::test() выдаст «A», а хотелось бы — что бы «B».
а я __callStatic жду. хочу чтобы можно было делать «registry» на уровне get::db()->…
Аналогично. 5.3 можно было бы выпускать только ради позднего статического связывания и __callStatic(), и это было бы уже очень полезно.
>Однако, в этом я вижу очень мало практического применения.
$var = $_GET['var'] :? 'default value'
$var = $_GET['var'] :? 'default value'
Вы ведь наверняка знаете:
В виду этого необходимо более сложное условие, нежели приведение строки к boolean'у.
var_dump('0' == FALSE);
// bool(true)
* This source code was highlighted with Source Code Highlighter.В виду этого необходимо более сложное условие, нежели приведение строки к boolean'у.
Более наглядный пример —
вместо
$entries = isset($entries)? $entries: array();
теперь можно просто
$entries = $entries ?: array();
вместо
$entries = isset($entries)? $entries: array();
теперь можно просто
$entries = $entries ?: array();
Вообще-то код ни разу не равнозначен, во втором случае будет Notice при отсутствии переменной.
Они наверное решили избавить программистов от половины нотисов ))) или немного сэкономить их пальцы при написании лишних буков
если честно, мне кажется код типа "$entries = $entries ?: array(); " не совсем читаемый, хотя программист ко всему привыкает…
если честно, мне кажется код типа "$entries = $entries ?: array(); " не совсем читаемый, хотя программист ко всему привыкает…
isset($entries) or $entries = array();
Кстати, конкретно для этого случая можно сделать
$entries = (array) $entries.
Во-первых вы будете уверены что всегда на вход попадет именно массив, во-вторых если ее нет — будеть создан пустой массив.
$entries = (array) $entries.
Во-первых вы будете уверены что всегда на вход попадет именно массив, во-вторых если ее нет — будеть создан пустой массив.
Логика не эквивалетна. Посмотрите как поведёт себя первый и второй код, если $entries = 1;
А разве в этом случае notice не появится?
Если переменная не определена, то появится. Мало того,
если $a = 1
$a = isset($a)? $a: array(); даст $a = 1;
$a = (array) $a; даст $a = array(1);
если $a = 1
$a = isset($a)? $a: array(); даст $a = 1;
$a = (array) $a; даст $a = array(1);
Не удалось нагуглить, но я почему-то уверен, что что $entries = $entries ?: array();
тоже будет давать notice.
тоже будет давать notice.
Не будет.
<?php
error_reporting(E_ALL);
$test = $test ?: 'nope';
var_dump ($test);
?>
error_reporting(E_ALL);
$test = $test ?: 'nope';
var_dump ($test);
?>
oops… я не разглядел, что вы конструкцию PHP5.3 там поставили. Всё-таки поздновато уже, в сон клонит.
Прошу прощения, отправил недописанный комментарий.
Этот код возвращает:
Notice: Undefined variable: test in Z:\test.php on line 3
string(4) «nope»
Ваша безапелляционность, кстати, убивает. Если не знаете, не говорите, пожалуйста.
Специально поставил PHP 5.3 свежий что бы это проверить.
Этот код возвращает:
Notice: Undefined variable: test in Z:\test.php on line 3
string(4) «nope»
Ваша безапелляционность, кстати, убивает. Если не знаете, не говорите, пожалуйста.
Специально поставил PHP 5.3 свежий что бы это проверить.
Млин… Я использовал для таких целей if (!is_array($var)) $var = array($var); :)
$var = $_GET['var']: $_GET['var']? 'default value';
$var = $_GET['var']: $_GET['var']? 'default value';
4. Тернарный оператор.
Можно использовать без указания true-альтернативы, тогда ей становится само значение.
…
Однако, в этом я вижу очень мало практического применения.
Например, когда нужно в начале функции проверить параметры, и, если хоть один не устраивает, просто вернуть false.
Пример из одного моего проекта:
static function add($tour, $date, $owner, $guest)
{
/*
* Проверка корректноcти параметров.
*/
$ret = self::$system_s->valid($tour, 'tour_id');
$ret = self::$system_s->valid($date, 'date') ? $ret : false;
$ret = self::$system_s->valid($owner, 'command_name') ? $ret : false;
$ret = self::$system_s->valid($guest, 'command_name') ? $ret : false;
if (!$ret)
{
return false;
}
//...
}
* This source code was highlighted with Source Code Highlighter.С новым синтаксисом подобная конструкция должна упроститься.
$ret = self::$system_s->valid($tour, 'tour_id')
&& self::$system_s->valid($date, 'date')
&& self::$system_s->valid($owner, 'command_name')
&& self::$system_s->valid($guest, 'command_name');
* This source code was highlighted with Source Code Highlighter.Мануал по неймспейсам в указанной вами ссылке морально устарел (3 марта прошлого года) и не соответствует реалиям.
Укажите эту ссылку, если не затруднит: php.net/namespaces
Укажите эту ссылку, если не затруднит: php.net/namespaces
Замыкания, конечно, сделали очень по-своему.
Про spl не написали. Там добавилось несколько структур данных, которые, при определенных кейзах могут быть применимы в качестве микрооптимизаций. Например, FixedArray. Ну и плюс это даст более здоровый и ясный код, что конечно субъективно.
Спасибо, напишу сейчас.
У меня результаты запросов из БД перегоняются в массив и оттуда обрабатываются. Потому как удобно. Так вот во многих случаях перегон в массив по времени занимает как запрос в базу.
Это не имеет отношения к сабжу. Вы в любом случае много раз копируете данные.
Приведу пример того, что я имею в виду.
Возьмем fixed array. Что мы о нем знаем — структура данных фиксированного размера. Ага, значит можно избежать медленного realloc. Уже хорошо. Индексами могут быть только integers. Значит есть надежда что там будет использоваться меньше памяти на элемент + операции побыстрее будут.
Посмотрим чего внутри:
cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_fixedarray.c?view=markup
realloc-а неявного нету. Я нашел только явно, при вызове resize. Но если вам это потребуется, вы не верно выбрали структуру данных :-)
Далее смотри основную стрктуру.
typedef struct _spl_fixedarray { /* {{{ */
long size;
zval **elements;
} spl_fixedarray;
Неплохо, сэкономиле на ключе, считатай размер элемента у нас long + zval(а там внутри union).
Операции тоже будут простыми:
read:
&element[index]
write:
elements[index] = value;
А это тоже самое, что:
*elements+index
То есть используется адресная арифметика, а это очень быстро.
Ну вроде как-то, думаю понятно о чем я хотел сказать.
Ну и вот, в контексте вашей программы, все это называется микрооптимизацией, которая даст вам сколько-нибудь процентов перформанса ну и доставит(йо, я ж теперь тоже могу выжимать поинты из кода, как заправский сишник, правильно выбирая структуры данных). :-))
Приведу пример того, что я имею в виду.
Возьмем fixed array. Что мы о нем знаем — структура данных фиксированного размера. Ага, значит можно избежать медленного realloc. Уже хорошо. Индексами могут быть только integers. Значит есть надежда что там будет использоваться меньше памяти на элемент + операции побыстрее будут.
Посмотрим чего внутри:
cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_fixedarray.c?view=markup
realloc-а неявного нету. Я нашел только явно, при вызове resize. Но если вам это потребуется, вы не верно выбрали структуру данных :-)
Далее смотри основную стрктуру.
typedef struct _spl_fixedarray { /* {{{ */
long size;
zval **elements;
} spl_fixedarray;
Неплохо, сэкономиле на ключе, считатай размер элемента у нас long + zval(а там внутри union).
Операции тоже будут простыми:
read:
&element[index]
write:
elements[index] = value;
А это тоже самое, что:
*elements+index
То есть используется адресная арифметика, а это очень быстро.
Ну вроде как-то, думаю понятно о чем я хотел сказать.
Ну и вот, в контексте вашей программы, все это называется микрооптимизацией, которая даст вам сколько-нибудь процентов перформанса ну и доставит(йо, я ж теперь тоже могу выжимать поинты из кода, как заправский сишник, правильно выбирая структуры данных). :-))
Мужик =)
Маленькая поправочка: long конечно же один, а не на каждый элемент.
на всяк. случай для особо придиривыч скобки поставлю:
*(elements+index)
:-)
*(elements+index)
:-)
> realloc-а неявного нету. Я нашел только явно, при вызове resize. Но если вам это потребуется, вы не верно выбрали структуру данных :-)
Поправочка :). Если она вам часто требуется, то вы неверно выбрали структуру данных.
Поправочка :). Если она вам часто требуется, то вы неверно выбрали структуру данных.
Жду-недождусь 5.3, сразу на нее перейду.
Я тоже. Поскольку я сам выбираю что использовать, обновлюсь сразу же. Думаю, ситуация довольно типична, и 5.3 станет распространенной версией с первых дней.
Я даже ставлю "// refactoring PHP 5.3" в тех местах кода, которые нужно будет переделать после перехода.
Я даже ставлю "// refactoring PHP 5.3" в тех местах кода, которые нужно будет переделать после перехода.
Если площадка позволяет, 5.3 можно по-трогать уже сейчас:
Win — windows.php.net/snapshots/
*nix — snaps.php.net/
Win — windows.php.net/snapshots/
*nix — snaps.php.net/
Жду-недождусь 6.0 с нативным юникодом. И чем больше жду, тем больше кажется, что не дождусь и перейду на питон.
Что, так много приходится с Unicode-строками работать? Imho, в реальном проекте очень мало такого, разве что функцию обрезания текста сделать.
Мне, например, приходится много работать с Unicode-строками. По-правде говоря, я 90% времени именно с ними и работаю.
Я тоже, но смысл был в том что специфика юникода вылазиет не столь уж часто. Если приноровиться. Хотя конечно native unicode будет очень приятен. Отпадет куча маленьких гемморойчиков.
Да? Попробуйте сделать dirname или realpath от Unicode-пути. Грабли возникают там, где не ждёшь.
Да. Проблемы. Но решаются они весьма просто. Если верно понимаю — dirname — с помощью рэгекспов, а realpath вообще опционален (без него кажется сильно может снижаться производительность в виндах. думаю не многие держат продуктовый php на виндах :))) )
А как вам такие Синглтоны в PHP >= 5.3 ?)
<?php
abstract class Singleton {
private static $instances = array();
public function __construct() {
$class = get_called_class();
if (array_key_exists($class, self::$instances))
trigger_error("Tried to construct a second instance of class \"$class\"", E_USER_WARNING);
}
public static function getInstance() {
$class = get_called_class();
if (array_key_exists($class, self::$instances) === false)
self::$instances[$class] = new $class();
return self::$instances[$class];
}
}
class A extends Singleton {
}
class B extends Singleton {
}
$a1 = A::getInstance();
$a2 = A::getInstance();
$b1 = B::getInstance();
$b2 = B::getInstance();
if (get_class($a1) == "A" &&
get_class($a2) == "A" &&
get_class($b1) == "B" &&
get_class($b2) == "B" &&
$a1 === $a2 &&
$b1 === $b2)
echo "All good\n";
else
echo "FAIL!\n";
?>
* This source code was highlighted with Source Code Highlighter.
Лучше бы работу сессий пофиксили
А что именно с ними не так? Где можно взглянуть на ваш bug report?
На мой взгляд, сессия в PHP сделана крайне ужасна.
При старте сессия в хедеры выставляет свой Cache-Control и Expire, жутко гадит на диск в temporary, это камень и в огород и чистильщика сессии. При большом посещении tmp просто засоряется до нельзя и при этом PHP каждый раз лезет в эту кучу что бы найти нужную сессию. Сейчас существует множество алгоритмов хранения данных на диске, почему бы не использовать их?
То есть всё время надо следить что бы сессия где-нибудь ещё не гадила.
Если из всех страниц сайта только на некоторых есть сессия то есть вероятность что при переходах на страницы без session_start сессия стухнет.
На основе претензий: почему session_start всегда должна быть до вывода данных? неужели нельзя считать SID из куки после начала вывода? Понимаю что ей ещё надо нагадить в хедеры, но если сессия стартуется только при некоторых условиях, приходится извращаться с ob_start.
Я уже не говорю об отсутствии безопасности. Если хочешь обезопасить сессию приходится всегда писать свою обвертку и в итоге обвёртка полностью заменяет сессию и тогда получаем ещё одну не используемую и не отключаемую функциональность.
Зачем анониму таскать SID? Таким образом каждый раз при анониме скрипт лезет в tmp и искать переменную авторизации в _SESSION, когда проверку авторизации можно было свести к проверке присутствия сессии.
При старте сессия в хедеры выставляет свой Cache-Control и Expire, жутко гадит на диск в temporary, это камень и в огород и чистильщика сессии. При большом посещении tmp просто засоряется до нельзя и при этом PHP каждый раз лезет в эту кучу что бы найти нужную сессию. Сейчас существует множество алгоритмов хранения данных на диске, почему бы не использовать их?
То есть всё время надо следить что бы сессия где-нибудь ещё не гадила.
Если из всех страниц сайта только на некоторых есть сессия то есть вероятность что при переходах на страницы без session_start сессия стухнет.
На основе претензий: почему session_start всегда должна быть до вывода данных? неужели нельзя считать SID из куки после начала вывода? Понимаю что ей ещё надо нагадить в хедеры, но если сессия стартуется только при некоторых условиях, приходится извращаться с ob_start.
Я уже не говорю об отсутствии безопасности. Если хочешь обезопасить сессию приходится всегда писать свою обвертку и в итоге обвёртка полностью заменяет сессию и тогда получаем ещё одну не используемую и не отключаемую функциональность.
Зачем анониму таскать SID? Таким образом каждый раз при анониме скрипт лезет в tmp и искать переменную авторизации в _SESSION, когда проверку авторизации можно было свести к проверке присутствия сессии.
1) вам никто не мешает перекрыть cache-control и expire. Тем более, что их выставляют не сессия, а PHP.
2) вам никто не мешает положить сессии не в каталог /tmp/, а в любой другой. Читайте мануал.
3) вам никто не мешает хранить сессии MySQL, SQLite, memcached и вообще в любом месте, где можно хранить сессии. Читайте мануал.
4) все сессии всегда устроены именно так — протухать через время, если нет активности. по определению.
5) session_start() нужно выдать header'ы, как вы справедливо заметили. ob_start — отличный механизм, улучшающий производительность и код, рекомендую его освоить, безотносительно сессий. в чём вопрос я не понял, вы на него отлично ответили.
6) сессии надо стартавать тогда, когда это необходимо. без вашего участия этого никто не сделает. это не какой-то недостаток сессий, а объективная реальность жизни, если бы компьютеры сами знали, что делать, программистов не было бы. так что ответ — стартуйте сессию, когда нужно. про безопасность я не понял. что вы там обезопасить собираетесь?
2) вам никто не мешает положить сессии не в каталог /tmp/, а в любой другой. Читайте мануал.
3) вам никто не мешает хранить сессии MySQL, SQLite, memcached и вообще в любом месте, где можно хранить сессии. Читайте мануал.
4) все сессии всегда устроены именно так — протухать через время, если нет активности. по определению.
5) session_start() нужно выдать header'ы, как вы справедливо заметили. ob_start — отличный механизм, улучшающий производительность и код, рекомендую его освоить, безотносительно сессий. в чём вопрос я не понял, вы на него отлично ответили.
6) сессии надо стартавать тогда, когда это необходимо. без вашего участия этого никто не сделает. это не какой-то недостаток сессий, а объективная реальность жизни, если бы компьютеры сами знали, что делать, программистов не было бы. так что ответ — стартуйте сессию, когда нужно. про безопасность я не понял. что вы там обезопасить собираетесь?
> 2) вам никто не мешает положить сессии не в каталог /tmp/, а в любой другой. Читайте мануал
Мои 5 копеек: никто также не мешает смонтировать каталог сессий в памяти (это просто проще, чем хранить их в MySQL, SQLite, memcached)
Мои 5 копеек: никто также не мешает смонтировать каталог сессий в памяти (это просто проще, чем хранить их в MySQL, SQLite, memcached)
Обычно памяти на сервере и так в обрез, а вы предлагаете её за какать сессиями.
Обычно, на сервере столько памяти сколько нужно в нормальных условиях. Если её не хватает, то её добавляют, если того требует задача.
Везёт Вам
сервер с 8 гигами памяти сейчас арендуется за 99 евриков, то есть почти нахаляву.
где такое?
hetzner.de, netdirekt.de например
ну может чуть больше стоит, но порядок цен тот-же
ну может чуть больше стоит, но порядок цен тот-же
в нетдиректе дополнительные 4 гига покупаются при оплате, галочку ставите просто
ну а в хетзнере www.hetzner.de/hosting/produkte_rootserver/ds8000/
к сожалению это все мало интересно для проектов с рос. аудиторией :-(
1) код сам по себе без всякого пояснения не должен пихать своё в одну из ответственных частей проектов — заголовки.
2) дело не в том что он сохраняет в /tmp дело в том что он создаёт много файлов в сумме, которые, уменьшают производительность из-за своей многочисленности.
3) имею ввиду хранение на диске, взять для примера хранение данных на диске у eAccelerator — просто и быстро (не про данные в памяти).
4) я вспомнил про давний баг. Суть его, что сессия может стухнуть раньше указного времени.
5) зачем ей слать хедеры (см 1)? где это описано в мануале, что он шлет свои хедеры? а главное — зачем?
6) Позволю не согласиться. Можно сделать старт сессии только один раз, последующие разы запускать из куки, иметь возможность остановить сессию (убрать SID из куки). Тогда вопрос авторизации сводится к наличию сессии. Но это уже мои приблуды, однако с php4 сессии почти никак не развиваются.
Вы, видимо, не использовали сессии помимо сессий PHP, ибо как, в Java, например, сессии сделаны намного лучше.
2) дело не в том что он сохраняет в /tmp дело в том что он создаёт много файлов в сумме, которые, уменьшают производительность из-за своей многочисленности.
3) имею ввиду хранение на диске, взять для примера хранение данных на диске у eAccelerator — просто и быстро (не про данные в памяти).
4) я вспомнил про давний баг. Суть его, что сессия может стухнуть раньше указного времени.
5) зачем ей слать хедеры (см 1)? где это описано в мануале, что он шлет свои хедеры? а главное — зачем?
6) Позволю не согласиться. Можно сделать старт сессии только один раз, последующие разы запускать из куки, иметь возможность остановить сессию (убрать SID из куки). Тогда вопрос авторизации сводится к наличию сессии. Но это уже мои приблуды, однако с php4 сессии почти никак не развиваются.
Вы, видимо, не использовали сессии помимо сессий PHP, ибо как, в Java, например, сессии сделаны намного лучше.
> 2) дело не в том что он сохраняет в /tmp дело в том что он создаёт много файлов в сумме, которые, уменьшают производительность из-за своей многочисленности.
Вы, простите, что за файловые системы используете, что многочисленность файлов так влияет на производительность?
> 5) зачем ей слать хедеры (см 1)? где это описано в мануале, что он шлет свои хедеры? а главное — зачем?
Слать заголовки ей надо, хотя бы для того, чтобы поставить свою куку. Как только вы прочитали в мануале (о! читали ли?) про куки — вопрос про заголовки должен был отпасть.
> 6) Позволю не согласиться. Можно сделать старт сессии только один раз, последующие разы запускать из куки, иметь возможность остановить сессию (убрать SID из куки). Тогда вопрос авторизации сводится к наличию сессии. Но это уже мои приблуды, однако с php4 сессии почти никак не развиваются.
О да. А данные сессии нам уже таки совсем не важны… То есть, если зайду на ваш проект с кукой PHPSESSID=trapped — вы будете считать меня авторизованным?
Вы, простите, что за файловые системы используете, что многочисленность файлов так влияет на производительность?
> 5) зачем ей слать хедеры (см 1)? где это описано в мануале, что он шлет свои хедеры? а главное — зачем?
Слать заголовки ей надо, хотя бы для того, чтобы поставить свою куку. Как только вы прочитали в мануале (о! читали ли?) про куки — вопрос про заголовки должен был отпасть.
> 6) Позволю не согласиться. Можно сделать старт сессии только один раз, последующие разы запускать из куки, иметь возможность остановить сессию (убрать SID из куки). Тогда вопрос авторизации сводится к наличию сессии. Но это уже мои приблуды, однако с php4 сессии почти никак не развиваются.
О да. А данные сессии нам уже таки совсем не важны… То есть, если зайду на ваш проект с кукой PHPSESSID=trapped — вы будете считать меня авторизованным?
1) он не пихает без поясенения. В документации всё описано.
2) как вы предлагаете решить эту проблему? Если у вас там копятся сотни тысяч файлов, то смените файловую систему или кладите сессии в другие места
3) вам никто не мешает сделать то же самое. смотрите в документацию. кстати, данных у eaccelerator сильно меньше, чем количество сессий на хорошо нагруженном проекте
4) расскажите подробнее
5) вы уверены, что читали документацию? если вам лень искать, то орентируйтесь на слово cookie
6) что значит «старт сессии» один раз. поясните.
Сессиям некуда развиваться. Они всё необходимое умеют.
2) как вы предлагаете решить эту проблему? Если у вас там копятся сотни тысяч файлов, то смените файловую систему или кладите сессии в другие места
3) вам никто не мешает сделать то же самое. смотрите в документацию. кстати, данных у eaccelerator сильно меньше, чем количество сессий на хорошо нагруженном проекте
4) расскажите подробнее
5) вы уверены, что читали документацию? если вам лень искать, то орентируйтесь на слово cookie
6) что значит «старт сессии» один раз. поясните.
Сессиям некуда развиваться. Они всё необходимое умеют.
> 3) имею ввиду хранение на диске, взять для примера хранение данных на
> диске у eAccelerator — просто и быстро (не про данные в памяти).
Стоит почитать мануал и, о чудо!
session.save_path string
There is an optional N argument to this directive that determines the number of directory levels your session files will be spread around in. For example, setting to '5;/tmp' may end up creating a session file and location like /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If.
> диске у eAccelerator — просто и быстро (не про данные в памяти).
Стоит почитать мануал и, о чудо!
session.save_path string
There is an optional N argument to this directive that determines the number of directory levels your session files will be spread around in. For example, setting to '5;/tmp' may end up creating a session file and location like /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If.
> 1) код сам по себе без всякого пояснения не должен пихать своё в одну из ответственных частей проектов — заголовки.
Если это документированное поведение, то вполне себе должен.
Если это документированное поведение, то вполне себе должен.
А что с ними не так? 0_0
Лейблы?? goto??? ааа…
все перехожу на python!
все перехожу на python!
Вас будут пытать паяльником если вы НЕ будете использовать лейблы?
Хм… объясните мне, пожалуйста, в чём недостаток goto, по вашему мнению?
Если вы мне скажете, что это снижает читаемость, то это только в коде-простыне, который сам по себе нечитаем.
Если вы мне скажете, что goto может войти внутрь цикла или функции, то это не так, не может, насколько я знаю, это не Си и тут есть ограничения.
Если вы мне скажете, что это снижает читаемость, то это только в коде-простыне, который сам по себе нечитаем.
Если вы мне скажете, что goto может войти внутрь цикла или функции, то это не так, не может, насколько я знаю, это не Си и тут есть ограничения.
Коммент на много минусов ;)
Во всех нормальных языках — пайтон, джава, с# (если память не изменяет) — в качестве разделителя почти всего используют "." и нет никаких проблем. Просто там интерпретаторы/парсеры/все что их касается сделаны четко и продуманно, а не представляют собой ебаное мессиво из хаков.
Пайтон, например, очень спланированный язык, если смотреть на его основные идеи и принципы, понимаешь, что использовать "." легко и просто. Статический метод фундаментально ничем не отличается от обычной функции, более того, даже класс и функция на самом низком уровне абстракции одно и тоже.
Посмотрите на грамматику питона или джавы и попробуйте найти ее для пхп (если ее вообще возможно для пхп составить). Сравните. Потом посмотрите висходники спагетти-код парсера (да и вообще ядра пхп). Все станет ясно как день.
Когда порядок с архитектурой и философией, тогда и синтаксис языка приятный, и стандартная библиотека спланированная и удобная, и быдлокодеров меньше.
Та команда, которая пыхает ПХП, — просто не понимает что она делает. Они не понимают, что такое язык программирования, они не понимают, что если все останется как есть — то пхп просто умрет. Они не смотрят в будущее, не видят, что для ПХП сделать нормальный JIT просто нереально. Не понимают, что пхп уже очень скоро просто не выдержит конкуренции с руби, пайтоном, и т.п… Единственные козыри — «высокая производительность» и «доступность на шаред хостингах»: первое уже не актуально, а второе — шаред хостинги серьезным людям даром не нужны.
Сравните вообще подход — питонщики прежде чем хоть как-то трогать код или концепции пишут PEP, обсуждают его, исследуют проблему. Потом реализуют. А в пхп — сначала реализуют, потом пушат в апстрим, через год рвут на голове волосы, и обсуждают как и что делать в чате. Делают новый быстрый хак, и забывают о нем. Это не команда, это просто толпа любителей, так серьезные вещи не делаются.
Неймспейсы — это всего лишь один из камней в их огород. Чем дальше копаешь — тем больше проблем.
RIP, PHP.
Во всех нормальных языках — пайтон, джава, с# (если память не изменяет) — в качестве разделителя почти всего используют "." и нет никаких проблем. Просто там интерпретаторы/парсеры/все что их касается сделаны четко и продуманно, а не представляют собой ебаное мессиво из хаков.
Пайтон, например, очень спланированный язык, если смотреть на его основные идеи и принципы, понимаешь, что использовать "." легко и просто. Статический метод фундаментально ничем не отличается от обычной функции, более того, даже класс и функция на самом низком уровне абстракции одно и тоже.
Посмотрите на грамматику питона или джавы и попробуйте найти ее для пхп (если ее вообще возможно для пхп составить). Сравните. Потом посмотрите в
Когда порядок с архитектурой и философией, тогда и синтаксис языка приятный, и стандартная библиотека спланированная и удобная, и быдлокодеров меньше.
Та команда, которая пыхает ПХП, — просто не понимает что она делает. Они не понимают, что такое язык программирования, они не понимают, что если все останется как есть — то пхп просто умрет. Они не смотрят в будущее, не видят, что для ПХП сделать нормальный JIT просто нереально. Не понимают, что пхп уже очень скоро просто не выдержит конкуренции с руби, пайтоном, и т.п… Единственные козыри — «высокая производительность» и «доступность на шаред хостингах»: первое уже не актуально, а второе — шаред хостинги серьезным людям даром не нужны.
Сравните вообще подход — питонщики прежде чем хоть как-то трогать код или концепции пишут PEP, обсуждают его, исследуют проблему. Потом реализуют. А в пхп — сначала реализуют, потом пушат в апстрим, через год рвут на голове волосы, и обсуждают как и что делать в чате. Делают новый быстрый хак, и забывают о нем. Это не команда, это просто толпа любителей, так серьезные вещи не делаются.
Неймспейсы — это всего лишь один из камней в их огород. Чем дальше копаешь — тем больше проблем.
RIP, PHP.
ЭЭЭ, перечитал. Наболело просто ;-)ТМ, R
Ну-ну, хватит холиваров. Не вы первый хороните пхп, не вы последний, а он ещё всех нас переживёт)
Я думаю Вас кто-то жестоко обманул.
1. JIT уже сделали, даже в различных модификациях.
2. Преимущество Python очень сомнительно, про Ruby даже не стоит говорить, это недоязык.
Была занимательная статья человека, который поддался новым веяниям и перешел на Ruby (переписал проект с нуля), потом понял что нет ничего что нельзя сделать на PHP и снова переписал проект с нуля на PHP. Советую почитать, познавательно.
3. PHP Team далеко не ламеры, код чистят и оптимизируют, парсер почти сделали новый.
4. Лично для меня главное преимущество PHP перед остальными скриптовыми языками — то что для меня (как и для большинства людей) он прост как семь копеек, т.е. заранее понятно как и что работает, что может тормозить, и т.д. Существует куча готовых решений практически для всего.
Если я на что-то и буду переходить, то на Java (уже сейчас использую), и очень маловероятно на Python.
5. Производительность кстати очень даже ничего, даже если использовать просто PHP + eAccelerator её более чем хватает (трудно упереться в микро-оптимизации). Если использовать к примеру phc, то феррари превращается в реактивный самолет.
6. Не вижу проблем с namespaces, думаю что оно и к лучшему что слеш используется, читабельнее будет.
1. JIT уже сделали, даже в различных модификациях.
2. Преимущество Python очень сомнительно, про Ruby даже не стоит говорить, это недоязык.
Была занимательная статья человека, который поддался новым веяниям и перешел на Ruby (переписал проект с нуля), потом понял что нет ничего что нельзя сделать на PHP и снова переписал проект с нуля на PHP. Советую почитать, познавательно.
3. PHP Team далеко не ламеры, код чистят и оптимизируют, парсер почти сделали новый.
4. Лично для меня главное преимущество PHP перед остальными скриптовыми языками — то что для меня (как и для большинства людей) он прост как семь копеек, т.е. заранее понятно как и что работает, что может тормозить, и т.д. Существует куча готовых решений практически для всего.
Если я на что-то и буду переходить, то на Java (уже сейчас использую), и очень маловероятно на Python.
5. Производительность кстати очень даже ничего, даже если использовать просто PHP + eAccelerator её более чем хватает (трудно упереться в микро-оптимизации). Если использовать к примеру phc, то феррари превращается в реактивный самолет.
6. Не вижу проблем с namespaces, думаю что оно и к лучшему что слеш используется, читабельнее будет.
Кстати, а вы знаете что PHP-код можно одной программулиной преобразовать в Java-код (JSP)?
И еще очень важный аргумент в выборе языка. PHP-программиста найти несравнимо проще чем программиста на Java или на Python'е. Так уж вышло, но это надо признать, и не строить иллюзорных идиллий.
И еще очень важный аргумент в выборе языка. PHP-программиста найти несравнимо проще чем программиста на Java или на Python'е. Так уж вышло, но это надо признать, и не строить иллюзорных идиллий.
> про Ruby даже не стоит говорить, это недоязык
У Ruby есть свои недостатки, но называть его «недоязыком» нельзя, хотя бы потому, что он является «допустимым лиспом» (http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp). Этот ваш человек наверняка попытался писать на Ruby также, как он до этого писал на PHP, что является фатальной ошибкой.
> PHP Team далеко не ламеры, код чистят и оптимизируют, парсер почти сделали новый.
Разговор был о том, что у Питона и Явы конкретный синтаксис определяется контекстно-свободной грамматикой, что само по себе большой плюс (если надо, раскрою эту мысль). Так ли это в PHP?
>> Статический метод фундаментально ничем не отличается от обычной функции, более того, даже класс и функция на самом низком уровне абстракции одно и тоже.
Это плюс. Язык должен быть непротиворечивым, фичи должны плавно вытекать одна из другой.
> он прост как семь копеек, т.е. заранее понятно как и что работает, что может тормозить, и т.д
Судя по Хабру, это не так. (Довольно часто встречаются статьи, которые раскрывают «хитрости» PHP и подобное.)
ЗЫ for great justice
У Ruby есть свои недостатки, но называть его «недоязыком» нельзя, хотя бы потому, что он является «допустимым лиспом» (http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp). Этот ваш человек наверняка попытался писать на Ruby также, как он до этого писал на PHP, что является фатальной ошибкой.
> PHP Team далеко не ламеры, код чистят и оптимизируют, парсер почти сделали новый.
Разговор был о том, что у Питона и Явы конкретный синтаксис определяется контекстно-свободной грамматикой, что само по себе большой плюс (если надо, раскрою эту мысль). Так ли это в PHP?
>> Статический метод фундаментально ничем не отличается от обычной функции, более того, даже класс и функция на самом низком уровне абстракции одно и тоже.
Это плюс. Язык должен быть непротиворечивым, фичи должны плавно вытекать одна из другой.
> он прост как семь копеек, т.е. заранее понятно как и что работает, что может тормозить, и т.д
Судя по Хабру, это не так. (Довольно часто встречаются статьи, которые раскрывают «хитрости» PHP и подобное.)
ЗЫ for great justice
> Довольно часто встречаются статьи, которые раскрывают «хитрости» PHP и подобное.
Хитрости и т. п. есть в любом достаточно большом и сложном программном продукте.
Хитрости и т. п. есть в любом достаточно большом и сложном программном продукте.
> Хитрости и т. п. есть в любом достаточно большом и сложном программном продукте.
Смотря какие. Одно дело, когда это искусственно введенные в язык правила (например, из-за особенностей реализации), другое — когда новые свойства можно легко и просто реализовать с помощью старых.
Ярким примером первого случая является Си++, второго — Scheme.
Смотря какие. Одно дело, когда это искусственно введенные в язык правила (например, из-за особенностей реализации), другое — когда новые свойства можно легко и просто реализовать с помощью старых.
Ярким примером первого случая является Си++, второго — Scheme.
Да не про хитрости статьи обычно. Статьи про пых делятся всегда на две категории (в более 9000% случаев):
1) статьи начинающих программистов как захачить вордпресс или установить модуль для друпаля
2) статьи «гуру» пхп, которые умудрились сделать нормальный синглтон, выебав себе мозг через get_debug_backtrace(). Или что-то в этом роде.
1) статьи начинающих программистов как захачить вордпресс или установить модуль для друпаля
2) статьи «гуру» пхп, которые умудрились сделать нормальный синглтон, выебав себе мозг через get_debug_backtrace(). Или что-то в этом роде.
Отлично что публикуют хитрости, значит кому-то из смертных они известны.
> 1. JIT уже сделали, даже в различных модификациях.
Линки в студию, желательно, на стабильные реализации рекомендованный в продакшен.
> 2. Преимущество Python очень сомнительно, про Ruby даже не стоит говорить, это недоязык.
Я не фанат Ruby, а вот про сомнительные преимущества хотелось бы услышать ;)
> 3. PHP Team далеко не ламеры, код чистят и оптимизируют, парсер почти сделали новый.
Могут чистить код сколько хотят. Задайтесь вопросом, почему у джавы, c#, пайтона большинство стандартной библиотеки написано на самом языке, а не на Си? Подумайте тщательно, заодно почитайте про JIT, LLVM etc
> 4. Лично для меня главное преимущество PHP…
Он на самом деле сложнее чем тот же питон. Я писал на пхп несколько лет, писал enterprise soft для крупных американских корпораций, честно говоря, был залочен на него. Знаю его сурсы, ибо приходилось фиксить баги, и сабмитить их в апстрим.
> 5 Производительность кстати очень даже ничего, даже если использовать просто PHP + eAccelerator…
Это временно. eAccelerator, APC — кривые костыли. Кстати, никогда не возникало вопроса почему они не включены в состав пхп? ;) Почитайте мэйллисты, а лучше подпишитесь на них, если вы действительно интересуетесь проектом.
> 6. Не вижу проблем с namespaces, думаю что оно и к лучшему что слеш используется, читабельнее будет.
Ну, бывают вкусы и поизвращеннее. Подождем, когда им понадобится еще один символ для грамматики. Может сделают два слеша? ;)
Линки в студию, желательно, на стабильные реализации рекомендованный в продакшен.
> 2. Преимущество Python очень сомнительно, про Ruby даже не стоит говорить, это недоязык.
Я не фанат Ruby, а вот про сомнительные преимущества хотелось бы услышать ;)
> 3. PHP Team далеко не ламеры, код чистят и оптимизируют, парсер почти сделали новый.
Могут чистить код сколько хотят. Задайтесь вопросом, почему у джавы, c#, пайтона большинство стандартной библиотеки написано на самом языке, а не на Си? Подумайте тщательно, заодно почитайте про JIT, LLVM etc
> 4. Лично для меня главное преимущество PHP…
Он на самом деле сложнее чем тот же питон. Я писал на пхп несколько лет, писал enterprise soft для крупных американских корпораций, честно говоря, был залочен на него. Знаю его сурсы, ибо приходилось фиксить баги, и сабмитить их в апстрим.
> 5 Производительность кстати очень даже ничего, даже если использовать просто PHP + eAccelerator…
Это временно. eAccelerator, APC — кривые костыли. Кстати, никогда не возникало вопроса почему они не включены в состав пхп? ;) Почитайте мэйллисты, а лучше подпишитесь на них, если вы действительно интересуетесь проектом.
> 6. Не вижу проблем с namespaces, думаю что оно и к лучшему что слеш используется, читабельнее будет.
Ну, бывают вкусы и поизвращеннее. Подождем, когда им понадобится еще один символ для грамматики. Может сделают два слеша? ;)
Эээ, интеллектуал каких мало, любитель скриптовых языков, боюсь тебя разочаровать, но вся-вся-вся грамматика PHP находится в исходниках в файле Zend/zend_language_parser.y — посмотри на досуге и удивись, что хаки, про которые ты говоришь — всего навсего давно известный YACC (Yet Another Compilers Compiler), великое изобретение человечества, на котором сделаны парсеры почти ко всем языкам программирования. Для начала советую попытаться разобраться в синтаксисе YACC самому и сделать какой-нибудь простенький язык программирования, райски удобный, а уже потом обвинять команду PHP в некомпетентности.
P.S. кстати, разобравшись, сможешь пропатчить с легкостью этот файл и поменять неугодный тебе -> на.
Обожаю фамильярность, сразу понятно с кем имеешь дело. Я опущусь на твой уровень в разговоре, хорошо?
>… но вся-вся-вся грамматика PHP находится в исходниках в файле Zend/zend_language_parser.y…
1000 строк против 100 у пайтона. Нуну. Это при том, что в пайтоне есть декораторы, множественное наследовние, мета классы, аннотации, генераторы. И не надо мне про PHP STL говорить, она дико тормозная, еще один костыль.
> Для начала советую попытаться разобраться в синтаксисе YACC самому и сделать какой-нибудь простенький язык программирования, райски удобный, а уже потом обвинять команду PHP в некомпетентности.
Сам пиши себе удобные языки. Мне же хватает уже написанных. Да и своих языков я написался как в университете, так и в проектах разных.
>… но вся-вся-вся грамматика PHP находится в исходниках в файле Zend/zend_language_parser.y…
1000 строк против 100 у пайтона. Нуну. Это при том, что в пайтоне есть декораторы, множественное наследовние, мета классы, аннотации, генераторы. И не надо мне про PHP STL говорить, она дико тормозная, еще один костыль.
> Для начала советую попытаться разобраться в синтаксисе YACC самому и сделать какой-нибудь простенький язык программирования, райски удобный, а уже потом обвинять команду PHP в некомпетентности.
Сам пиши себе удобные языки. Мне же хватает уже написанных. Да и своих языков я написался как в университете, так и в проектах разных.
В PHP файл с грамматикой в 10 раз больше только потому, что в нем, помимо грамматики, находятся правила для YACC, из которых генерируется парсер языка. Обратите внимание — генерируется, именно поэтому я и говорю, что вооружившись терпением, изменить язык PHP так, как это угодно вам — задача не невозможная.
Сильно сомневаюсь, что в университете и в ваших проектах вам доводилось сталкиваться с настоящими лексерами.
Сильно сомневаюсь, что в университете и в ваших проектах вам доводилось сталкиваться с настоящими лексерами.
>… помимо грамматики, находятся правила для YACC…
Честно говоря, не обратил внимания. В любом случае, 400 строк… Не сильно лучше.
> Сильно сомневаюсь, что в университете и в ваших проектах вам доводилось сталкиваться с настоящими лексерами.
Ну да, не буду спорить. Но тем не менее, как показала практика, моих знаний вполне достаточно чтобы написать парсеры xpath и xquery, отличить top-down от bottom-up, или CFG от RG, ну и для того, чтобы трезво смотреть на некоторые вещи.
Честно говоря, не обратил внимания. В любом случае, 400 строк… Не сильно лучше.
> Сильно сомневаюсь, что в университете и в ваших проектах вам доводилось сталкиваться с настоящими лексерами.
Ну да, не буду спорить. Но тем не менее, как показала практика, моих знаний вполне достаточно чтобы написать парсеры xpath и xquery, отличить top-down от bottom-up, или CFG от RG, ну и для того, чтобы трезво смотреть на некоторые вещи.
Это не трезвый взгляд, поверьте. Почти каждый (я и в том числе) сталкивался в своей жизни с необходимостью что-то парсить, и успешно решал эту задачу. Я вот, как выше говорил, темплейтными движками увлекался (пытался сделать универсальный и действительно _удобный_ метод шаблонизации). В какой-то момент я жестко уперся рогом в проблему баланса производительности/универсальности-удобства и стал копать в сторону YACC/FLEX — вот тут то и открылся мне этот волшебный мир во всей своей красе. (Скажу честно, до конца довести начатое у меня не хватило ни творческого запала, ни возможности тратить много времени на настоящее программирование, а не тупое клепание сайтов с целью извлечения биовыживательных бумажек) Из этого могу сказать вот что — парсинг всего, что связано с XML — это рай, по сравнению со всем остальным, отчасти потому что именно для простоты парсинга все эти технологии и были придуманы.
Я знаю ;)
По поводу действительно удобного метода шаблонизации, это конечно веха та еще.
Напишите плиз, что вы под этим понимаете? Может я подскажу что уже есть и вам еще не довелось встретить?
По поводу действительно удобного метода шаблонизации, это конечно веха та еще.
Напишите плиз, что вы под этим понимаете? Может я подскажу что уже есть и вам еще не довелось встретить?
Как минимум (то, над чем я корпел тогда, сейчас уже сам весь в сомнениях) — хотя бы базовый функционал смарти (циклы и ветвления, циелы обязательно конечно же с условиями аля start/step/max), работа с глобальными, а не локальными, переменными (как в vBulletin, без необходимости тыщи раз делать $template->assign, но, самое главное, с возможностью защиты от перезаписи важных переменных) и, самое главное, автоматическая мультиязычность (возможность, при парсинге HTML, автоматически выделять те строки, которые в дальнейшем нужно будет перевести, вставлять их в языковую таблицу, а в темплейт на их место вставлять {$blabla} (при рендеринге, само собой, забирать из языковой таблицы нужные строки в нужном языке и возвращать на место). Последний пункт — это гвоздь программы (но есть и другие интересные функции, которые уже кстати реализованы, но еще не очень хорошо отлажены/отпрофилены)
> без необходимости тыщи раз делать $template->assign
У нас наверное с вами немного разные подходы к разработке, ибо у меня получается всегда один вызов $template->assign на проект ;) Код темплейта желательно тоже держать зажатым, чтобы избежать ошибок и багов, так что я убежден, что глобальные переменные там — зло.
По поводу автоматического перевода, — здесь нужен безусловно XML движок. В мире пайтона есть два, на которые я бы посоветовал обратить внимание — Genshi и TAL. У последнего, есть клон на пхп — PHPTAL (http://phptal.org/). Если там нет перевода «из коробки», то его точно можно будет добавить. Зато есть аутоэскейпинг ;)
У нас наверное с вами немного разные подходы к разработке, ибо у меня получается всегда один вызов $template->assign на проект ;) Код темплейта желательно тоже держать зажатым, чтобы избежать ошибок и багов, так что я убежден, что глобальные переменные там — зло.
По поводу автоматического перевода, — здесь нужен безусловно XML движок. В мире пайтона есть два, на которые я бы посоветовал обратить внимание — Genshi и TAL. У последнего, есть клон на пхп — PHPTAL (http://phptal.org/). Если там нет перевода «из коробки», то его точно можно будет добавить. Зато есть аутоэскейпинг ;)
По поводу текущей «дискуссии», если ее можно так назвать, я высказался ниже, в ответе на вопль некого Sherman81. Можно закрывать, думаю ;)
Zend/zend_language_parser.output, раздел Grammar — 409 строчек — да, в 4 раза больше, но именно поэтому PHP гораздо популярнее, чем Python, среди начинающих веб-разработчиков.
Вот непонимаю, как сложность и запутанность грамматики языка кореллирует с его популярностью? Петросян тоже популярен. А вот вопрос как так, при значительно более мощном языке, грамматика у тогоже пайтона меньше в 4 раза?
Вопрос не в «мереньи письками», мне было бы абсолютно пофигу на грамматику пхп, но просто видно следствия из этого.
И не сможешь ты заменить. на ->. У тебя будут большие проблемы с тем, как отличить это дело от оператора конкатенации. Пример: $obj->some_var — все хорошо, теперь заменяем: $obj.some_var — что написано? Написано, сконкатенируй мне $obj и константу some_var. Если константы нет — то сконкатенируй строку 'some_var' и кинь нотис. Вот теперь подумай, это нормальный язык?
Вопрос не в «мереньи письками», мне было бы абсолютно пофигу на грамматику пхп, но просто видно следствия из этого.
И не сможешь ты заменить. на ->. У тебя будут большие проблемы с тем, как отличить это дело от оператора конкатенации. Пример: $obj->some_var — все хорошо, теперь заменяем: $obj.some_var — что написано? Написано, сконкатенируй мне $obj и константу some_var. Если константы нет — то сконкатенируй строку 'some_var' и кинь нотис. Вот теперь подумай, это нормальный язык?
Я думаю, своей популярности PHP обязан не сложностью и запутанностью (как, в моем представлении, пайтон или там перл например), а как раз наоборот, простотой и доходчивостью. Именно для этого и необходима столь огромная грамматика, чтобы дурак не промахнулся, если что.
Что мешает заменить оператор конкатенации на что-то еще? Кстати, его можно поменять на плюс (+) и написать очень небольшую обертку на си для корректного определения типа переменной в этом случае — для себя же делаешь, в конце концов.
Что мешает заменить оператор конкатенации на что-то еще? Кстати, его можно поменять на плюс (+) и написать очень небольшую обертку на си для корректного определения типа переменной в этом случае — для себя же делаешь, в конце концов.
можно поменять на плюс (+)
Нет. Нельзя. Раздутая грамматика в php это следствие динамической типизации и безумного количества правил приведения типов. В таких языках тип результата определяется не типами аргументов, а типом оператора.
Сравни:
var_dump(1 + 1); # (int) 2 var_dump(1 . 1); # (string) "11"
Это не недостаток. Просто особенность данного класса языков — для каждого типа оператора нужна своя «закорючкя». Такие языки не позволяют определять пользовательские операторы. Поэтому обилие встроенных операторов никому не мешает. Чем больше операторов встроено в язык, тем он богаче, однозначнее и лаконичнее. В perl, например, их еще больше. :)
Основной недостаток грамматики php это обилие ключевых слов (зарезервированных). Именно поэтому в классах нельзя называть методы именами 'and', 'or', 'use', 'require' и т.п.
Кому как, я например вообще использую строгую типизацию в пхп (вида $user_id = (int) $_GET['user_id']) везде где только можно, и я не особо замечу, если динамическая типизация пропадет (а делается для себя, напоминаю). Кстати, это бывает полезно: в 2002 году я очень намучался с одним платежным gateway'ем, написанным на PHP — в случае, если CVV код карточки начинался с нуля (или, не дай бог, с двух налей) — транзакция отклонялась! Быстро было обнаружено, что это долбанный пхп автоматически считает тип поля CVV int'ом и убирает лишние нули сначала — в итоге год становится двух (или одно) значным и не проходит.
Насчет зарегистрированных слов — если они Вам мешают и Вы им не пользуетесь, милости просим в те самые файлы с исходниками — все эти слова описаны там и еще легче могут быть оттуда убраны.
Насчет зарегистрированных слов — если они Вам мешают и Вы им не пользуетесь, милости просим в те самые файлы с исходниками — все эти слова описаны там и еще легче могут быть оттуда убраны.
Это не PHP долбаенный, это кто-то про sprintf не слышал.
Поверьте, _тогда_ все это не помогало ни капли, ни sprintf, ни жесткая типизация, ни даже просто присобачивание нолика слева вручную, если длина меньше трех — все равно, при склеивании запроса длинна цвв становилась равной двум. Более того (говорю же, сам гейтвей был на пхп), даже если вручную отправлялся запрос с правильным цвв, все равно на том конце ноль куда то терялся.
использую строгую типизацию в пхп (вида $user_id = (int) $_GET['user_id'])Это называется приведением типа. Случись, что php станет строго типизированным, это выражение не скомпилируется, поскольку int и user_id — разные типы данных (у них алгебры разные, скажем, выражение [int] + [int] = [int] законно, а [user_id] + [user_id] не имеет смысла). :)
Насчет зарегистрированных слов — если они Вам мешают и Вы им не пользуетесь, милости просим в те самые файлы с исходниками — все эти слова описаны там и еще легче могут быть оттуда убраныМир возможного вообще чудесен. ;) Тем не менее, в реальности, по мере роста версии php, словарь зарезервированных слов языка только расширяется.
Я в курсе, как это называется. А вот насчет [user_id] + [user_id] что-то не понял?
Алгебраически, идентификаторы — самостоятельный тип данных, не похожий на [int]. Идентификаторы бессмысленно делить, умножать, возводить в степень, и делать с ними еще много других операций, которые обычно свойственны целым числам [int]. Идентификаторы можно лишь сравнивать между собой. Множество допустимых значений идентификаторов пользователя конечно — оно определяется множеством значений, заданных в соответствующей таблице БД. В итоге, все эти ограничения формируют тип [user_id]. В строго типизированных языках, переменные так же типизированы. Переменная $user_id будет иметь тип [user_id]. А поскольку в таких языках автоматическое преобразование типов не допускается, то попытка присвоить $user_id = (int) … неизбежно приведет к ошибке. В php'шном синтаксисе подражание строгой типизации выглядит так:
$user_id = user_id::from_string($_GET['user_id']);полагая, что user_id::from_string это конструктор объекта типа [user_id].
Вы наивный, немного ;) Только не обижайтесь.
"." на "+" поменять не сможете. Можно на ";)" думаю. Кстати, по поводу последнего смайл-оператора, они его на полном серьезе обсуждали в качестве разделителя нэймспейсов. Как им можно доверять?
Мой вам совет — уделите время изучению других платформ. Хуже точно не будет.
Удачи!
"." на "+" поменять не сможете. Можно на ";)" думаю. Кстати, по поводу последнего смайл-оператора, они его на полном серьезе обсуждали в качестве разделителя нэймспейсов. Как им можно доверять?
Мой вам совет — уделите время изучению других платформ. Хуже точно не будет.
Удачи!
Я там уже объяснил выше, почему лично я смогу легко поменять его на плюс — я по старой привычке в нужных местах сам всегда делаю жесткое приведение типов ($test = (int) $_GET['test']; $key = (string) $_GET['key'];), не полагаюсь на капризный местами механизм в пхп, и у меня всегда (ну, почти) переменные нужных типов. Соответственно, для меня не проблема пропатчить обработку оператора сложения для работы только со строгими типами данных, без приведения.
По поводу других платформ — знали бы Вы, сколько их я изучил за свою жизнь!..
По поводу других платформ — знали бы Вы, сколько их я изучил за свою жизнь!..
Python далеко не продуманный язык. Я это заметил за срок меньший года.
Есть прекрасные статьи на сайте IBM по критике языка Python, там тоже всё запущено.
Есть прекрасные статьи на сайте IBM по критике языка Python, там тоже всё запущено.
> Python далеко не продуманный язык. Я это заметил за срок меньший года.
Примеры есть? Или просто мелем языком?
Примеры есть? Или просто мелем языком?
Вы читать до конца умеете?
Написано: «Есть прекрасные статьи на сайте IBM по критике языка Python, там тоже всё запущено».
Вот сайт IBM: ibm.com
Вот поиск: google.com
Вот конструкция, чтобы искать на сайте ibm: «site:ibm.com». Вперёд. Или мне вам статьи в комментарий скопипастить?
Написано: «Есть прекрасные статьи на сайте IBM по критике языка Python, там тоже всё запущено».
Вот сайт IBM: ibm.com
Вот поиск: google.com
Вот конструкция, чтобы искать на сайте ibm: «site:ibm.com». Вперёд. Или мне вам статьи в комментарий скопипастить?
Я читал немало статей на разные темы там, в том числе и про пайтон. И не видел критики ;) Так что скопипасть сюда урлы.
То, что ты освоил поиск в гугле — это хорошо, хороший пхпед ;)
То, что ты освоил поиск в гугле — это хорошо, хороший пхпед ;)
Освой и ты поиск в Гугле и не морочь мне голову. Хочется знаний, учись их сам получать.
А ты научись грамотно выделяться из стада, не «тыкать», и не писать реплики вроде «я что-то где-то слышал, кто-то что-то говорил, я ваще нихера там не понимаю, ищи в гугле» — от них ни холодно ни жарко.
Не ссорьтесь. Imho, большой разницы нет между. и ->, дело привычки, я уже давно пишу задумываясь не о синтаксисе, а об алгоритме. Вы же когда пишите текст, не задумываетесь о красоте букв и слов, вы просто их используете.
Да мне-то без разницы. Я пишу на самых разных языкам, мне всё равно как в очередном языке делается вызов метода.
Ага, вы правы.
Как по мне — да, разницы нет. Я просто хотел расскзать чем она обусловлена, показать проблему. Но любая критика пхп — это все равно, что разбежаться и стукнуться об бетонную стену — результат тот же.
Как по мне — да, разницы нет. Я просто хотел расскзать чем она обусловлена, показать проблему. Но любая критика пхп — это все равно, что разбежаться и стукнуться об бетонную стену — результат тот же.
Посмотри-ка мой коммент выше. Там написано «вы», потом идёт твой с фразой «ты освоил поиск в гугле». Хочешь, чтобы тебе не тыкали, не тыкай первым.
Если ты мне пишешь такие вещи, то, видимо, ты каким-то чудом меня не знаешь, товарищ нуб.
Если ты мне пишешь такие вещи, то, видимо, ты каким-то чудом меня не знаешь, товарищ нуб.
Ну и чтобы закончить этот глупый спор, попробую воспользоваться Гуглом и даю ссылки на две статьи:
www.ibm.com/developerworks/ru/library/l-python-elegance-1/index.html
www.ibm.com/developerworks/ru/library/l-python-elegance-2/index.html
остальные сам найдёшь
www.ibm.com/developerworks/ru/library/l-python-elegance-1/index.html
www.ibm.com/developerworks/ru/library/l-python-elegance-2/index.html
остальные сам найдёшь
Вы попросту врете, да-да, нагло врете.
>А в пхп — сначала реализуют, потом пушат в апстрим, через год рвут на голове волосы, и обсуждают как и что делать в чате. Делают новый быстрый хак, и забывают о нем. Это не команда, это просто толпа любителей, так серьезные вещи не делаются.
Все значимые фитчи обсуждаются в internals, как и конкретные патчи.
Плюс, есть еще закрытое обсуждение между ключевыми разработчиками.
>А в пхп — сначала реализуют, потом пушат в апстрим, через год рвут на голове волосы, и обсуждают как и что делать в чате. Делают новый быстрый хак, и забывают о нем. Это не команда, это просто толпа любителей, так серьезные вещи не делаются.
Все значимые фитчи обсуждаются в internals, как и конкретные патчи.
Плюс, есть еще закрытое обсуждение между ключевыми разработчиками.
Зачем же так эмоционально, неужели я начинаю потрясать устои вашего пхп-мира? Не переживайте так ;) Это все пустое, инструмент есть инструмент, надо им уметь пользоваться. Одно дело, инструмент может быть удобным и приятным на ощупь, другое — он может быть пхп.
По поводу «врете» — я не вру, именно так все и работает. Кто-то захотел что-то сделать, стучится в аську кому-то другому, вместе на айрси что-то быстро обсуждают и добавляют. В пайтон-коммьюните — сначала пишут PEP — пропозал, потом он долго обсуждается (без всяких internals) — любой может прийти и написать свое менение, и только потом это идет в апстрим. Разницу подхода чувствуете? Если нет, то наверное, стоит посетить университет еще раз. Опять-таки, это картина «в целом и общем», некоторые вещи они долго обсуждают, некоторые не очень.
В любом случае, мне рассуждать на эту тему надоело, хотите — пишите, мне то что? Я лишь хотел, чтобы неглупые в принципе люди, которых тут много, взяли и уделили немного времени на нормальные языки — пайтон, лисп, смаллтолк, хаскель (любой можно выбрать и изучить). Тогда и придет осознание почему к пхп такое отношение.
В общем, дисукуссию можно считать закрытой. Удачи.
По поводу «врете» — я не вру, именно так все и работает. Кто-то захотел что-то сделать, стучится в аську кому-то другому, вместе на айрси что-то быстро обсуждают и добавляют. В пайтон-коммьюните — сначала пишут PEP — пропозал, потом он долго обсуждается (без всяких internals) — любой может прийти и написать свое менение, и только потом это идет в апстрим. Разницу подхода чувствуете? Если нет, то наверное, стоит посетить университет еще раз. Опять-таки, это картина «в целом и общем», некоторые вещи они долго обсуждают, некоторые не очень.
В любом случае, мне рассуждать на эту тему надоело, хотите — пишите, мне то что? Я лишь хотел, чтобы неглупые в принципе люди, которых тут много, взяли и уделили немного времени на нормальные языки — пайтон, лисп, смаллтолк, хаскель (любой можно выбрать и изучить). Тогда и придет осознание почему к пхп такое отношение.
В общем, дисукуссию можно считать закрытой. Удачи.
Дискуссия в стиле «я Пастернака не читал, но осуждую».
===========================================
Ну вот видите, вы снова врете.
Где вы увидели в моей посте эмоции? :-) (вот первая).
Просто констатация факта, и все. Люблю называть вещи своими именами, фетиш у меня такой.
Мало того что вы врете, вы делаете это еще и нагло. Потому что любой кто читает рассылку php может без труда вспомнить обсуждение нескольких патчей namespace и много другого. Также можно найти архивы через гугл.
===========================================
Ну вот видите, вы снова врете.
Где вы увидели в моей посте эмоции? :-) (вот первая).
Просто констатация факта, и все. Люблю называть вещи своими именами, фетиш у меня такой.
Мало того что вы врете, вы делаете это еще и нагло. Потому что любой кто читает рассылку php может без труда вспомнить обсуждение нескольких патчей namespace и много другого. Также можно найти архивы через гугл.
Блин, да задолбали вы меня своим «врете» ;) Я работал в стартапе с одним из разработчиков PHP (входит, я думаю, в 10ку первых), он был там один из директоров, где и с каким — говорить не могу из-за подписанного NDA. И знаю об этой кухне от «первого лица». И ему, далеко неглупому человеку, тоже не нравилось как принимаются решения по поводу развития языка.
Можете своим рогом сколько угодно долбить стену ;) Удачи еще раз.
Можете своим рогом сколько угодно долбить стену ;) Удачи еще раз.
Tits or GTFO :-)
Фамилию разработчика в студию?
Пока все что вы говорите похоже просто на то что вы говорите то, в чем совершенно не разбираетесь, потому что ни одного аргумента в поддержку своего наезда вы не привели.
Фамилию разработчика в студию?
Пока все что вы говорите похоже просто на то что вы говорите то, в чем совершенно не разбираетесь, потому что ни одного аргумента в поддержку своего наезда вы не привели.
Я, кажется, привел достаточно аргументов, читайте выше. Не достаточно — может быть в другом топике потроллим еще ;)
А с фамилией — я уже один раз в своей жизни NDA нарушал, и срал под диван потом несколько месяцев, как к адвокату сходил ;) Так что больше не в этой жизни.
А с фамилией — я уже один раз в своей жизни NDA нарушал, и срал под диван потом несколько месяцев, как к адвокату сходил ;) Так что больше не в этой жизни.
Поверьте, ни одного.
Ладно, еще разок. Что вы можете сказать про тот факт, что все значимые вещи обсуждаются в internals, на dev-канале, в личной переписке, в community.
Вы же утверждали обратное, а именно:
>А в пхп — сначала реализуют, потом пушат в апстрим, через год рвут на голове волосы, и обсуждают как и что делать в чате. Делают новый быстрый хак, и забывают о нем. Это не команда, это просто толпа любителей, так серьезные вещи не делаются.
Какие вы привели аргументы?
Ладно, еще разок. Что вы можете сказать про тот факт, что все значимые вещи обсуждаются в internals, на dev-канале, в личной переписке, в community.
Вы же утверждали обратное, а именно:
>А в пхп — сначала реализуют, потом пушат в апстрим, через год рвут на голове волосы, и обсуждают как и что делать в чате. Делают новый быстрый хак, и забывают о нем. Это не команда, это просто толпа любителей, так серьезные вещи не делаются.
Какие вы привели аргументы?
Хочется отметить, что при использовании phar происходит одна оригинальная вещь: ряд привычных функций PHP (например, fopen) подменяется т. н. функциями-перехватчиками, определенными в phar. Из-за этого в ранних версиях PHP-5.3 было иногда почти невозможно работать, я лично до сих пор отключаю phar при сборке — от греха подальше.
Хмм, возможно по это причние у меня не получилось «упаковать» весь сайт в один phar.
С include_path более менее разборался, а с проблемой записи во всякие log/upload/tmp/cache не получилось «разрулить», отложил в сторону затею.
Думаю пройдет некоторое время пока не появятся внятные туториалы по использованиею phar. (:
С include_path более менее разборался, а с проблемой записи во всякие log/upload/tmp/cache не получилось «разрулить», отложил в сторону затею.
Думаю пройдет некоторое время пока не появятся внятные туториалы по использованиею phar. (:
2. Closures.
Отметим, что заключительная точка с запятой — обязательна.
Отметим: ключевое слово $this использовать в коде лямбды нельзя (сначала было можно, потом эту возможность убрали, сейчас разработчики решают, как быть: с реализацией возникли проблемы). В общем, это не так плохо: можно обойтись так:
… но здесь появляются ограничения: доступен только публичный интерфейс.
4. Тернарный оператор.
Мне кажется, именно практического применения будет очень много :)
грязновато, конечно, зато коротко и ясно. Свои плюсы и свои минусы.
7. SPL.
Во-первых: http://www.php.net/~helly/php/ext/spl/
И кроме того, о значимых нововведениях (честно говоря, не в курсе, может быть, все то же самое есть и не только в 5.3): SplStack, SplDoublyLinkedList, SplQueue, SplPriorityQueue.
Посмотреть информацию о классах, интерфейсах и функциях Spl можно в phpinfo() или из командной строки:
$ php -i|less
$ php -r 'var_export(spl_classes());'
$ php --re spl|less
$lambda = function() {echo 'Hello World!';};Отметим, что заключительная точка с запятой — обязательна.
$func = function() use ($var) {echo $var;};Отметим: ключевое слово $this использовать в коде лямбды нельзя (сначала было можно, потом эту возможность убрали, сейчас разработчики решают, как быть: с реализацией возникли проблемы). В общем, это не так плохо: можно обойтись так:
$that = $this; $func = function() use ($that) {echo $that->someMethod();};… но здесь появляются ограничения: доступен только публичный интерфейс.
4. Тернарный оператор.
Однако, в этом я вижу очень мало практического применения.
Мне кажется, именно практического применения будет очень много :)
echo @$var['name'] ?: '—';
грязновато, конечно, зато коротко и ясно. Свои плюсы и свои минусы.
7. SPL.
Во-первых: http://www.php.net/~helly/php/ext/spl/
И кроме того, о значимых нововведениях (честно говоря, не в курсе, может быть, все то же самое есть и не только в 5.3): SplStack, SplDoublyLinkedList, SplQueue, SplPriorityQueue.
Посмотреть информацию о классах, интерфейсах и функциях Spl можно в phpinfo() или из командной строки:
$ php -i|less
$ php -r 'var_export(spl_classes());'
$ php --re spl|less
Интересно теперь, насколько Label'ы будут убивать проект по производительности и как их будут вылавливать, правя код за ньюбами.
Я нигде не встречал информации о том, какие IDE уже поддерживают php5.3, или, хотя бы, когда планируются к выпуску обновления. Хабрасообщество подскажет?
/* Как я понял, Zend 5.5 обновлять не будут? :( */
/* Как я понял, Zend 5.5 обновлять не будут? :( */
Ещё
Прочитал
Phar архивы стали нативными. Просто офигительная штука!
Заметил
Все функции eregi_* депрекэйтед заметил когда открыл phpMyAdmin
Делимитер для нэймспейсов просто неудачный выбор
Жду не дождусь
Когда примитивные типы обернут классами тогда мой велосипед станет полностью оо
Прочитал
Phar архивы стали нативными. Просто офигительная штука!
Заметил
Все функции eregi_* депрекэйтед заметил когда открыл phpMyAdmin
Делимитер для нэймспейсов просто неудачный выбор
Жду не дождусь
Когда примитивные типы обернут классами тогда мой велосипед станет полностью оо
> Однако, в этом я вижу очень мало практического применения.
раньше \надоедает\:
$page = isset($_GET['page'])?$_GET['page']:1;
сейчас \радует\:
$page = isset($_GET['page'])?:1;
раньше \надоедает\:
$page = isset($_GET['page'])?$_GET['page']:1;
сейчас \радует\:
$page = isset($_GET['page'])?:1;
Кстате, раньше небыло магического метода __invoke
Вот много в коментах грязи вылито на пхп, много народ пишет о руби, питоне, яве, си. Просто есть соразмерность средств и целей, есть разные методы достижения целей. И если бы не было пхп или чего-то подобно-простого в плане изучения и использования, то многие цели так и не были бы достигнуты. Наверно иногда стоит об этом задуматься, перед тем, как заниматься обкладыванием…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP 5.3: обзор