Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 234
А какой смысл писать что-то не для сайтов на PHP?
А почему бы и нет. PHP — скриптовый язык программирования общего назначения ru.wikipedia.org/wiki/PHP
Про консольные утилиты, надеюсь, никто не говорит. Поэтому можно предположить нечто из разряда демонов. А не подходит PHP для них, именно потому что предназначен для сайтов. Время жизни исполняемого кода очень низкое. Это оставляет сильный отпечаток на той же работе с памятью.
ЗЫ:… и это если очередной раз не тыкать палочкой в то, как язык PHP был спроектирован
ЗЫ:… и это если очередной раз не тыкать палочкой в то, как язык PHP был спроектирован
Почему бы и не консольные? Да и демон вполне может быть для сайтов, вроде даже веб-серверы есть чисто на php, как и тру fastcgi. По-моему, с полгода как у php с временем жизни кода и утечками памяти проблем не больше, чем у других языков его класса.
Если нужна программа в ограниченные сроки, то лучше, имхо, воспользоваться хорошо знакомым языком, чем начинать изучать новый, пускай и теоретически лучше подходящий для этой задачи, тм более если языки из одной весовой категории (я про php/python/ruby/perl). Новые языки надо изучать или just for fun, или если работодатель/заказчик согласен оплачивать вхождение и допускает повышенную вероятность срыва сроков. Рассуждать про себя в стиле «на хабре в комментах пишут, что писать на python/ruby быстрее, чем на php, но я их не знаю толком, потому возьму времени как на php» несколько неэтично, имхо — может прокатит, а может нет. У меня вот с python не прокатило, хорошо хватило времени переписать всё в авральном режиме на php+gtk.
Если нужна программа в ограниченные сроки, то лучше, имхо, воспользоваться хорошо знакомым языком, чем начинать изучать новый, пускай и теоретически лучше подходящий для этой задачи, тм более если языки из одной весовой категории (я про php/python/ruby/perl). Новые языки надо изучать или just for fun, или если работодатель/заказчик согласен оплачивать вхождение и допускает повышенную вероятность срыва сроков. Рассуждать про себя в стиле «на хабре в комментах пишут, что писать на python/ruby быстрее, чем на php, но я их не знаю толком, потому возьму времени как на php» несколько неэтично, имхо — может прокатит, а может нет. У меня вот с python не прокатило, хорошо хватило времени переписать всё в авральном режиме на php+gtk.
5.3 со сборщиком мусора всё гораздо лучше чем раньше
Время жизни у них бесконечное, если не скапливать в памяти классы и переменные.
у меня был демон-парсер на PHP, работал больше месяц без перерыва. я его завершил только потому, что захотел изменить конфигурацию.
Вот представте на минуту что знаете только PHP и вам вдруг понадобилось быстренько написать какую то консольную утилиту, которая скажем файлики перегоняет из одной кодировки в другую.
Вы скорее всего быстренько набросаете ее на PHP и будете радоваться тому что успеете сделать что то еще.
Вы скорее всего быстренько набросаете ее на PHP и будете радоваться тому что успеете сделать что то еще.
В который раз отпишусь — любой язык это инструмент — плохой или хороший, удобный или неудобный это решать тому человеку кто его использует. Вы просто не умеете его готовить :-D И это — Ваши проблемы.
Обезьяне все равно что у нее в руках — линейка или лазерный дальномер — применет она его всегда одинаково :P
Обезьяне все равно что у нее в руках — линейка или лазерный дальномер — применет она его всегда одинаково :P
В 19 лет это часто случается — хочется многое, если не все, изменить, а уверенность в полном познании чего-либо — непоколебима. Нет, ну серьезно.
Пардон, 20.
аргументируй. чего ему не хватает чтобы быть СОВРЕМЕННЫМ. думаю, ты расскажешь лишь о фишках, которые даже древнее самого php.
к сожалению, даже древние вещи, как метопрограммирование, популярный нынче тред, но он так и не смог обрасти нормальной методологией разработки. Ява модель является единственным отточенным инструментом, для которого есть ножны чтобы не пораниться. В php используется такой же подход.
ой, посмотрел ваш профиль. вы же просто тролль, не знающий ничего о потребностях разработки.
к сожалению, даже древние вещи, как метопрограммирование, популярный нынче тред, но он так и не смог обрасти нормальной методологией разработки. Ява модель является единственным отточенным инструментом, для которого есть ножны чтобы не пораниться. В php используется такой же подход.
ой, посмотрел ваш профиль. вы же просто тролль, не знающий ничего о потребностях разработки.
Да просто старайтесь потоньше троллить. А то не интересно даже становится.
то, что ты напишешь в профиле не важно, а вот комменты твои почитав становится понятен типаж.
сплошь вода и отсутствие конкретики, вот и сейчас тупо уход от конкретного вопроса об аргументах. начитался чужих мыслей и мнений в интернетах и вперёд на подвиги достойные ксерокса.
сплошь вода и отсутствие конкретики, вот и сейчас тупо уход от конкретного вопроса об аргументах. начитался чужих мыслей и мнений в интернетах и вперёд на подвиги достойные ксерокса.
словосочетание «морально устаревший», применяемое по отношению к языку — это просто смешно.
В следующий раз, когда соберетесь писать подобную глупость, вспомните, что
1. Часть программы, при помощи которой Вы собираетесь запостить подобную глупость, написана на устаревшем C, а часть на Assembler, из которого вообще песок сыпется.
2. Сайт, на который Вы собираетесь запостить глупость, использует устаревшую спецификацию языка, основанного на устаревшем XML ( аж от 1999 года!!! — что на целых пять лет старше текущей версии PHP)
3. А запрос, который поместит Вашу глупостьь в базу, будет написан на устаревшем языке запросов, и размещать все это он будет в базу данных с устаревшей реляционной парадигмой хранения.
В следующий раз, когда соберетесь писать подобную глупость, вспомните, что
1. Часть программы, при помощи которой Вы собираетесь запостить подобную глупость, написана на устаревшем C, а часть на Assembler, из которого вообще песок сыпется.
2. Сайт, на который Вы собираетесь запостить глупость, использует устаревшую спецификацию языка, основанного на устаревшем XML ( аж от 1999 года!!! — что на целых пять лет старше текущей версии PHP)
3. А запрос, который поместит Вашу глупостьь в базу, будет написан на устаревшем языке запросов, и размещать все это он будет в базу данных с устаревшей реляционной парадигмой хранения.
А как Вы меряете устаревание языка? По каким параметрам?
Вы будете удивлены, каждый год создается очередной язык «изначально проектировавшийся чтобы сделать разработку под встроенные системы удобней, чем при использовании C + ASM»
Уже создано Over 9000 стандартов, которые парсятся быстрее, удобней для восприятия человеком, занимают меньше места, чем XML.
Про SQL и HTML 4 я вообще молчу. Почитайте блог NoSql и пару статей про HTML5
Вы будете удивлены, каждый год создается очередной язык «изначально проектировавшийся чтобы сделать разработку под встроенные системы удобней, чем при использовании C + ASM»
Уже создано Over 9000 стандартов, которые парсятся быстрее, удобней для восприятия человеком, занимают меньше места, чем XML.
Про SQL и HTML 4 я вообще молчу. Почитайте блог NoSql и пару статей про HTML5
Запрос в гугл на фразу «Php устарел» приводит нас на один форум, где идет вялый холивар ниочем.
Так что, к сожалению, Вашу аргументацию без пруфлинка я принять не смогу.
Так что, к сожалению, Вашу аргументацию без пруфлинка я принять не смогу.
> А узнать про «устаревание языка» вы сможете поискав это в гугле
С этого и надо было начинать: что вы считаете это так, потому что «народ так говорит». В вашем возрасте довольно типично принимать на веру мнение нескольких гуру, не особо разбираясь почему они так считают. В противном случае, вы приводили бы аргументы, а не ссылались на «общественное мнение».
С этого и надо было начинать: что вы считаете это так, потому что «народ так говорит». В вашем возрасте довольно типично принимать на веру мнение нескольких гуру, не особо разбираясь почему они так считают. В противном случае, вы приводили бы аргументы, а не ссылались на «общественное мнение».
Чувак, ну ты жжош, ты наверно до сих пор живешь 4-м PHP )))).
Давай минусуй карму в отместку. )))).
Давай минусуй карму в отместку. )))).
Реализовано, и реализовано отлично, чуть менее чем полностью как в яве, в яве по-вашему тоже ООП нет? А где тогда есть? :) Вы тогда пишите уж более предметно чего вам не хватает.
Аргументируйте.
Реально единственный аргумент — это то, что базовые типы не являются объектами.
Но это без проблем обходится.
Еще напрягает неявное преобразвание типов, сложно разобраться откуда какие данные идут.
Но к этому привыкаешь.
Нередко встречался с неудачным использованием магических методов. Но это скорее исключение.
Да на самом деле, для любого языка можно наскрести таких «недостатков» и таких «но».
А проще всего не ныть. А то придется отрезать то, что танцевать мешает.
Но это без проблем обходится.
Еще напрягает неявное преобразвание типов, сложно разобраться откуда какие данные идут.
Но к этому привыкаешь.
Нередко встречался с неудачным использованием магических методов. Но это скорее исключение.
Да на самом деле, для любого языка можно наскрести таких «недостатков» и таких «но».
А проще всего не ныть. А то придется отрезать то, что танцевать мешает.
Конечно PHP уныверсальный язык
1. Для Web
2. Для скриптов
3. для разработки десктопных приложений habrahabr.ru/blogs/php/19004/
При наличии правильного набора расширений на PHP можно писать практически все.
Другое дело, что его для этих целей не используют, потому что есть промышленные стандарты и более удобные решения для программистов.
1. Для Web
2. Для скриптов
3. для разработки десктопных приложений habrahabr.ru/blogs/php/19004/
При наличии правильного набора расширений на PHP можно писать практически все.
Другое дело, что его для этих целей не используют, потому что есть промышленные стандарты и более удобные решения для программистов.
Проблема скорее в том что некоторые относятся к PHP с предвзятостью основанной на слухах и мнениях ;)
Да я не смеюсь.
Вы конкретно напишите, что вас так смешит, возможно мы можем подискутировать по поводу этого и я вас скорее всего смогу убедить что в общем целом в php имеет вполне добный ООП подход.
Отвечаю сразу же на предполагаемые вопросы:
> Множественного наследования где?
— Есть, через интерфейсы, как в Java и С#
> Проперти где?
— Есть, но честное слово не пользуюсь, и в советах по оптимизации тоже не советуют. (ввиду того что это интерпретируемый язык), лучше пользоватся методами.
> PHP говно, медленно работает
Упс, пишите либы для PHP на чистейшем Си, а можете и на C++
> (задаем математически) PHP говно, потому что это говно, потому что это говно, ..., потому что это говно.
Ничем прокомментировать не могу. Вероятно вы правы.
На другие вопросы тоже попробую ответить.
Вы конкретно напишите, что вас так смешит, возможно мы можем подискутировать по поводу этого и я вас скорее всего смогу убедить что в общем целом в php имеет вполне добный ООП подход.
Отвечаю сразу же на предполагаемые вопросы:
> Множественного наследования где?
— Есть, через интерфейсы, как в Java и С#
> Проперти где?
— Есть, но честное слово не пользуюсь, и в советах по оптимизации тоже не советуют. (ввиду того что это интерпретируемый язык), лучше пользоватся методами.
> PHP говно, медленно работает
Упс, пишите либы для PHP на чистейшем Си, а можете и на C++
> (задаем математически) PHP говно, потому что это говно, потому что это говно, ..., потому что это говно.
Ничем прокомментировать не могу. Вероятно вы правы.
На другие вопросы тоже попробую ответить.
> PHP имеет популярность, как язык на котором можно за 1 день научиться клепать сайты и быдлокодить на фрилансе — и это печально
С другой стороны, это говорит о простоте и хорошей реализации под конкретную задачу, что можно отнести к достоинствам. Никто не начинает с первого дня писать хороший код, нужно время проб и ошибок, в котором будет и быдлокод. Тот кто быдлокодер по сути — будет быдлокодить на любом языке, кто растет со временем — будет писать хороший код и на бейсике
С другой стороны, это говорит о простоте и хорошей реализации под конкретную задачу, что можно отнести к достоинствам. Никто не начинает с первого дня писать хороший код, нужно время проб и ошибок, в котором будет и быдлокод. Тот кто быдлокодер по сути — будет быдлокодить на любом языке, кто растет со временем — будет писать хороший код и на бейсике
Знаю, например, PHP, C, Asm, основы Java, Erlang и Common Lisp. На чём из них мне писать одноразовую консольную утилиту, к которой основное требование скорость разработки?
Лучше воспользоваться iconv из командной строки, чем из командной строки вызывать php передавая ему php код, который вызывает iconv
Если задача чуть посложнее, чем перекодировка одного файла с известным именем в другой файл с известным именем, то «обвязку» для вызова iconv делать придётся по любому. Так ли велика разница делать её средствами sh или php? Особенно, если второй язык знаешь намного лучше, чем первый, а сделать надо вчера.
Ну там может быть нужно не просто конвертировать, а ещё с какой-то заковыкой, которая потребует как минимум знания sh. А человек его не знает. Зато знает php.
Некоторое время назад я познакомился с python, и понял, что я терял все это время.
через некоторое время вы познакомитесь с Java (Modula, Ruby, Scala, C# выбрать, подставить из списка своё) и так же подумаете.
Уверен, что большей языка-помойки, чем php, из более менее современных языков я уже не найду.
Хотя что же я… Есть еще его уродливый брат-близнец — perl…
Все таки области применения у них разные, так что ваше «брат-близнец» как-то не совсем к месту.
Вспомнилась великолепная цитата:
PHP — это маленькое зло, созданное некомпетентными новичками, в то время как Perl — это большое и коварное зло, созданное умелыми, но извращенными профессионалами.
— Jon Ribbens
Вспомнилась великолепная цитата:
PHP — это маленькое зло, созданное некомпетентными новичками, в то время как Perl — это большое и коварное зло, созданное умелыми, но извращенными профессионалами.
— Jon Ribbens
Вот про Perl зря вы, если вы не знаете языка, то иногда лучше помолчать, а то ведь холиварить просто, а выложить по существу архитектуры языка будет сложнее.
Области применения разные? Вы данную статью читали?
Ви таки вапгосами изволите-с?
Читал и что с областями не так? Сделал человек модель языка Forth молодец, в чем проблема и почему у него всё работает, а вам не нравится?
Читал и что с областями не так? Сделал человек модель языка Forth молодец, в чем проблема и почему у него всё работает, а вам не нравится?
Что именно про Perl я «зря»? То, что его код выглядит одинаково до и после RSA шифрования?
У него всего работает, только причем здесь это? Фома и Ерема?
У него всего работает, только причем здесь это? Фома и Ерема?
Вы, видимо еще не освоили языки, после которые у вас возникает отвращение как php, так и к perl.
У вас горячка, нормально читается код на Perl, RSA шифрование это лишь глупая шутка, если вы не знаете какого-то языка и не умеете на нём читать, то это лишь ваша проблема, он не становится хуже от этого, сотни тысяч других людей умеют и любят читать Perl листинги.
Я например по китайски не умею читать, но при этом не ругаю его, учу.
Я например по китайски не умею читать, но при этом не ругаю его, учу.
Все верно, в тру языках необходимо предупреждать, что файл закодирован:
#!/usr/bin/python
# Did you know Python can use any obscure encoding: rot13, zlib, among others, for the source code?
cevag h"Uryyb jbeyq!"
Что ж вы так. Не зная броду, головой в воду ;)
Perl подарил миру такую замечательную вещь как регулярные выражения. Библиотека PCRE ( дословная расшифровка — регулярные выражения как в перле) нынче является неотъемлемым атрибутом любого приложения связанного с web.
Не зарекайтесь ;-)
Не подумает :)
Некоторое время назад я познакомился тоже с Python, и понял, что не терял ничего все это время. В итоге я учился программировать а не PHP, это не одно и то же.
В автолоадере, чтобы не было конфликтов, надо не эксепшн кидать, а возвращать false, чтобы передать управление следующему автолоудеру.
а зачем, если использовать язык на 100%, реализовывать стек и очередь, когда есть SplStack и SplQueue? ;) Кроме того, синглетоны — плохая практика (привет, глобалс!) и там не нужны
Я вот тоже не понял, зачем там Синглтон. Наверное, просто слово модное.
Вообще незачем, конечно. Исключительно ради одной вещи — показать LSB в действии. Искал наглядный пример.
Получилось плохо. Совсем не в тему.
Вообще, синглтон — плохой паттерн. Точнее он не плохой сам по себе, но то, как его суют везде, где он не нужен — просто кошмар.
Соглашусь.
Но все-таки, по существу — что крайне плохого в class A extends Singleton {}?
Но все-таки, по существу — что крайне плохого в class A extends Singleton {}?
Плохого, что в данном контексте он совершенно не нужен. А в extends Singleton, по сути, плохого почти ничего. Синглтон так редко нужен, что не имеет смысла создавать отдельный класс, от которого наследовать. Проще каждый раз прям в классе добавлять данные, а единственный родительский класс оставить для чего-то другого. Примесей ведь в php пока нету.
То есть в данном учебном примере «по сути, плохого почти ничего».
Ну и отлично.
Ну и отлично.
Нет, не переворачивайте мои слова и не выдирайте их контекста.
В данном учебном примере «всё ужасно» потому что вы даёте ещё один плохой пример новичкам использовать синглтон там, где он _совершенно_ не нужен.
В записи «class A extends Singleton» вне контекста — ничего плохого нету, но она бывает нужна крайне редко.
Но, еще раз повторю, именно в этом контексте такая запись — крайне вредная, потому что она учить людей делать неправильно!
В данном учебном примере «всё ужасно» потому что вы даёте ещё один плохой пример новичкам использовать синглтон там, где он _совершенно_ не нужен.
В записи «class A extends Singleton» вне контекста — ничего плохого нету, но она бывает нужна крайне редко.
Но, еще раз повторю, именно в этом контексте такая запись — крайне вредная, потому что она учить людей делать неправильно!
Я понял, есть два мнения — Ваше и неправильное.
Спасибо за разъяснение.
Спасибо за разъяснение.
Я понял, есть два мнения — Ваше и неправильное.
Боюсь это не только его мнение, но и мое.
А конкретно почему плох
А конкретно почему плох
Queue extends Singleton. Что делать, если в будущем нужны будут две разные очереди?Убрать extends Singleton.
Добавить abstract class Queue.
Отнаследовать от него Queue1 и Queue2.
Добавить abstract class Queue.
Отнаследовать от него Queue1 и Queue2.
Что отлично то? Хорошего и полезного тоже ничего нет. Для демонстрации LSB есть более удачные примеры. Например, ActiveRecord
Singleton нужно использовать тогда и только тогда, когда стоит ограничение на количество объектов — может существовать только один объект данного класса и большее количество обрушит систему или разрушит логику приложения.
Вы же использовали Singleton потому что была нужна только одна очередь.
Вы же использовали Singleton потому что была нужна только одна очередь.
Если Вы показываете новый фичи PHP 5.3 на таком примере, то где же __callStatic, __invoke и, конечно же, goto?
Похоже, 5.3 дает писать на джаве на пхп. Но корней не скроешь: "
require __DIR__ . '/' . implode('/', array_map('strtolower', $path)) . '/' . $filename . '.php';" — срыв башки вообще.ну этот кусок можно переписать проще ведь:
require sprintf('%s/%s/%s.php', __DIR__, strtolower(implode('/', $path)), $filename);И чем стало проще, кроме того, что Вы искуственно зачем-то ограничили число уровней вложенности?
Спасибо, прямо полегчало. :) Я, честно, очень давно уже на пхп не писал, но смутно припоминаю всю эту кошмарную идею с автолоадом. Это чтобы имя класса поменять, надо еще и файл переименовать? Эээ, а версии контролировать не надо? Представляю себе version hell, когда появляется обертка какого-нибудь корневого класса. Хотя может я и неправ, и никто так не делает, и это просто чтобы «проиллюстрировать LSB», или как там говорится.
а в Java разве не надо переименовывать файлы? В пхп да, обычно имя класса == название файлу, структура папок должна повторять структуру неймспейса. На деле сложно конечно, но в то же время и удобнее
А что сложного то?
Мне с моей С# колокольни и навязчивыми предупреждениями от СтайлКопа по другому и не видиться.
Мне с моей С# колокольни и навязчивыми предупреждениями от СтайлКопа по другому и не видиться.
Многим видится излишней структура «один файл — один класс», дублирование сущностей. Кажется ненужной роскошью выделять отдельный файл под класс из трёх-пяти строк, пока проект помещается в голове и/или умная IDE помогает перейти к определению класса или вставить отсутствующий include.
Многим видится излишней вообще хоть какая-то структура, но это не значит, что не нужно структурировать код.
Когда структурирование кода приводит к нарушению DRY (а «1 файл = 1 класс» — именно такой случай), встает вопрос сразу о полезности такого структурирования (или об адекватности языковых средств?).
DRY и KISS — это конечная цель любого структурирования, любого паттерна проектирования и т.д. Это базовые понятия, которые определяют, хороший код или плохой. Паттерны проектирования, соглашения насчет каких-то правил — это лишь средства достижения DRY и KISS, а не самоцель.
Необходимость создавать по файлу для каждого класса — это нарушение как DRY, так и KISS. Почему эта необходимость возникает возникает (из-за неадекватности языковых средств? из-за «архитекторов», которым хочется создавать «архитектуру»?) — это уже другой вопрос. Можно придумать ситуации, когда такой подход будет оправданным, но «по дефолту» — подход кажется неверным.
DRY и KISS — это конечная цель любого структурирования, любого паттерна проектирования и т.д. Это базовые понятия, которые определяют, хороший код или плохой. Паттерны проектирования, соглашения насчет каких-то правил — это лишь средства достижения DRY и KISS, а не самоцель.
Необходимость создавать по файлу для каждого класса — это нарушение как DRY, так и KISS. Почему эта необходимость возникает возникает (из-за неадекватности языковых средств? из-за «архитекторов», которым хочется создавать «архитектуру»?) — это уже другой вопрос. Можно придумать ситуации, когда такой подход будет оправданным, но «по дефолту» — подход кажется неверным.
Аргументируйте. В каком месте это нарушение DRY и, тем более, KISS? Вы предлагаете хранить всё в одном файле?
Между прочим, Java иначе и не позволяет орудовать с собой.
Между прочим, Java иначе и не позволяет орудовать с собой.
DRY очевидно — повтор имени неймспейса и класса в пути и имени файла. Если не использовать autoload, то и KISS под вопросом — инклудить, скажем, два файла вместо одного явно не проще.
Автолоад использовать, естественно.
Хорошо, какая альтернатива такому подходу? Хранить всё в одном файле?
Хорошо, какая альтернатива такому подходу? Хранить всё в одном файле?
Не умножать сущности сверх необходимого. Фактически для меня в таких ситуациях стоит выбор между DRY и KISS. То ли использовать простую схему отображения неймспейсов и классов на ФС, то ли путём усложнения autoload объединять связанные классы (родитель-наследники или сущность-хранилище, или ещё что-то) в одном файле.
хорошая альтернатива уродливому автолоаду такая:
<?php
spl_autoload_extensions(".php");
spl_autoload_register();
?>
Хм, а это не очевидно? Имя класса дублируется. Я предлагаю хранить как удобнее и понятнее, а не повторять названия классов названия классов в обязательном порядке. KISS — что для добавления класса мне нужно создавать новый файл, помещать его куда-то, добавлять в систему контроля версий; при переименовании класса, например, следить не только за исходным кодом, но и за файловой системой.
А Java за такие штуки и не любят. Я понимаю, что вопрос решается умными IDE, которые сами все создадут где нужно, и заготовки напишут. Но читать-то это IDE потом за человека не будет.
А Java за такие штуки и не любят. Я понимаю, что вопрос решается умными IDE, которые сами все создадут где нужно, и заготовки напишут. Но читать-то это IDE потом за человека не будет.
Стоп. Так какая альтернатива то? Хранить весь код в одном файле?
Эм, а у нас что-ли 2 варианта только — либо все, либо ничего?) Либо весь код в одном файле, либо каждый класс в отдельном? Хранить так, как удобнее и понятнее. Разбивать все на модули, в модуле — от 0 до N классов (и прочих штук), а не обязательно 1.
В commonjs и в python это на отлично сделано, в php с неймспейсами вроде тоже получше должно было стать (правда это уже сам не пробовал, т.к. несколько лет на php не писал).
В commonjs и в python это на отлично сделано, в php с неймспейсами вроде тоже получше должно было стать (правда это уже сам не пробовал, т.к. несколько лет на php не писал).
Угу, значить «файл на модуль»?
Да, так. При этом подходе DRY не нарушается, т.к. объединение сущностей в модуль несет дополнительный смысл. Сравните, например, подход «по файлу на класс» с тем, как бы это было написано на python (и на javascript).
php/классофайлы:
потом в глобальном контексте можно использовать ChartDashboardModule.
python/commonjs:
а потом можно использовать так, например:
или так:
Вариант с классофайлами без неймспейсов нарушает DRY в 2 местах:
FooDashboardModule повторяется в имени файла и названии класса. Кроме того, повторяется суффикс DashboardModule, который дублирует информацию о том, что классы лежат в dashboard/modules.
php/классофайлы:
dashboard/
modules/
BaseDashboardModule.php
class BaseDashboardModule {
// ...
ChartDashboardModule.php
class ChartDashboardModule extends BaseDashboardModule {
// ..
потом в глобальном контексте можно использовать ChartDashboardModule.
python/commonjs:
dashboard/
modules.py
class BaseModule(object):
#...
class Chart(BaseModule):
# ...
а потом можно использовать так, например:
import dashboard.modules module = dashboard.modules.Chart()
или так:
from dashboard import modules module = modules.Chart()
Вариант с классофайлами без неймспейсов нарушает DRY в 2 местах:
FooDashboardModule повторяется в имени файла и названии класса. Кроме того, повторяется суффикс DashboardModule, который дублирует информацию о том, что классы лежат в dashboard/modules.
Я понял вашу мысль. В ней есть рациональное зерно.
Моя практика показывает, что лучше в этом случае пожертвовать DRY в угоду KISS, а не наоборот, но холиварить не хочу.
Моя практика показывает, что лучше в этом случае пожертвовать DRY в угоду KISS, а не наоборот, но холиварить не хочу.
Холиварить тоже не хочу, но все ж в упор не понимаю, какие преимущества с точки зрения KISS у верхнего варианта: там же вдвое больше кода и вдвое больше файлов, да еще и со страшными именами все)
Возможно, впрочем, я каких-то деталей реализации этих подходов в php не учитываю.
Возможно, впрочем, я каких-то деталей реализации этих подходов в php не учитываю.
Ну смотрите. Вот в JS я пользуюсь тем же подходом. Да и в Джаве — тоже. В чём его преимущество? Вот я хочу найти класс Rectangle модуля Shapes. Я иду в директорию Shapes и открываю файл Rectangle. А так у меня будет файл-модуль Shapes, где мне надо будет искать класс Rectangle.
Я хочу одновременно редактировать два класса одного модуля. Каждый класс как раз умещается на экран. Мне достаточно клацать по вкладкам в нетбинсе, чтобы переключаться между классами.
Ну это пара из преимуществ.
Я хочу одновременно редактировать два класса одного модуля. Каждый класс как раз умещается на экран. Мне достаточно клацать по вкладкам в нетбинсе, чтобы переключаться между классами.
Ну это пара из преимуществ.
Класс в одном файле сделан для удобства:
есть два класса А и Б
А — абстракнтый системный
Б — Наследник
Я хочу класс Б заменить своим Ц
Пишу Ц, кладу его _естественно_ не в одну даже папку с абстрактным, так как тот системный, а Ц лично мой, в итоге мне класс Б не нужен, и он не подгружается никогда.
А вообще, автолоад для того и сделан чтоб искуственно управлять путями, Вы можете класть абстрактные файлы вместе с наследниками, это ничего не поломает, можете хоть по 10 классов сунуть в один файл, просто Вам надо будет как нить в дальнейшем их доставать, это уже придется реализовать самому.
есть два класса А и Б
А — абстракнтый системный
Б — Наследник
Я хочу класс Б заменить своим Ц
Пишу Ц, кладу его _естественно_ не в одну даже папку с абстрактным, так как тот системный, а Ц лично мой, в итоге мне класс Б не нужен, и он не подгружается никогда.
А вообще, автолоад для того и сделан чтоб искуственно управлять путями, Вы можете класть абстрактные файлы вместе с наследниками, это ничего не поломает, можете хоть по 10 классов сунуть в один файл, просто Вам надо будет как нить в дальнейшем их доставать, это уже придется реализовать самому.
Зачем экономить файлы?
Много файлов сложно держать в голове и в окошке файл-менеджера не помещаются :)
А вообще и объективные показатели есть. Когда CMS или фрэймворк для вывода «hello world» инклудят пару тысяч файлов, то выполнение скрипта это несколько задерживает, даже при использовании кэширования диска — один файл на пару мегабайт инклудится быстрее. Правда лично для меня это оправданием никогда не было, кроме случаев когда в огромные нечитаемые куски кода собираются файлы чисто на продакшене.
А вообще и объективные показатели есть. Когда CMS или фрэймворк для вывода «hello world» инклудят пару тысяч файлов, то выполнение скрипта это несколько задерживает, даже при использовании кэширования диска — один файл на пару мегабайт инклудится быстрее. Правда лично для меня это оправданием никогда не было, кроме случаев когда в огромные нечитаемые куски кода собираются файлы чисто на продакшене.
Вы большинство из них не трогаете, многие файлы/классы самодостаточны. Если я скачиваю библиотеку, мне не важно сколько в ней файлов, если мне нужно что-то изменить я создаю свой один файл и наследуюсь от нужного класса, где он лежит меня уже не волнует, у меня есть свой.
Я говорю, прежде всего, о соглашениях в своём приложении. В сторонний код редко приходится лазить, согласен и какое там количество файлов не суть, главное чтобы не было конфликтов между autoload. И говорю о ситуации когда мои классы довольно тесно и однозначно между собой связаны, например, наследованием, композицией или фабричными методами, причём реализации некоторых из них весьма примитивны и не требуют больше экрана кода.
Ну если в коде только собственные файлы, то как расставлять классы — причуды автора этого кода, можно и все в одном, это не запрещено, просто из пира пошла такая традиция (один класс = один файл, название класса = путь к файлу + название класса), он раздается пакетами, может путь питона хотели эмулировать, может еще где присмотрели, я не вкурсе, но после работы с таким подходом он кажется удобным =)
Всё в одном перебор, конечно, в большинстве случаев. Посмотрел соглашения об именах — не увидел требования или даже рекомендации «один файл — один класс», только «Иерархия классов PEAR также отражается на именах классов, каждый уровень отделяется знаком подчеркивания», что, кажется, несколько другое.
Именно из-за имени Вы не сможете положить два класса в один файл, ибо их придется (потому как соглашения имен) назвать одинаково, а это нельзя делать
В соглашениях имён я не увидел ничего об именовании файлов, только именование классов нашёл. Полностью доки, правда, не читал, только выборочно по нашей теме.
Вопрос субъективного удобства — мне проще выбирать файлы визуально мышкой, чем помнить тонкости написания их имён, да ещё для рутинных задач писать регулярные выражения, которые вводить ручками. *sh для меня инструмент для установки и запуска mc. При необходимости могу без последнего обойтись, но лишь действительно при необходимости. Хотя когда-то не понимал зачем нужны [nc,vc].com :) и, тем более, мышка. Но как-то теперь трудно без неё, может потому что скорость «зрячей» печати у меня раза в 3-4 выше слепой (200-300 vs. 70-80).
Пару комментариев из серии «сравнения» и «мнения».
1) > Мы с самого начала договорились с вами, что пишем на PHP 5.3, а это значительно облегчает работу
системному архитектору.
— Достаточно спорное утверждение. Хорошему системному архитектору достаточно UML. Ему до низких материй, таких как языки программирования, вообще далеко. Теоретически архитектор обычно сидит и рисует квадратики на листе.
— Если честно, то я считал и буду считать, что Скриптовый!!! PHP не создан для тяжелых сложных архитектур постоянно весящих в памяти, на нем из-за его типизации приходится очень аккуратно кодить, малыми кусками. Для тяжести и жести мне кажется Java или C# самое то + ультимейтная студия с UML. А так сам PHP чрезвычайно легок и быстр для работы с текстами, выборками БД, любыми скриптовыми обработками (то есть алгоритмы на нем приятно делать, компилятор написать например можно теоретически но не сложную систему, ввиду скриптовости и динам. типизацией), etc. Но обычно для сайтов применяется и все, что еже с ними ибо на нем можно быстро написать, а потом, если есть желание наприсать ввиде C++ либы, увелича скорость до теоретически максимальной (так делается на любых крапных проектах)
Коммент из серии «оценка».
Статья хорошая, ваш код понравился. Не скрою впервые увидел неймспейсы, спасибо буду думать куда можно это применить.
1) > Мы с самого начала договорились с вами, что пишем на PHP 5.3, а это значительно облегчает работу
системному архитектору.
— Достаточно спорное утверждение. Хорошему системному архитектору достаточно UML. Ему до низких материй, таких как языки программирования, вообще далеко. Теоретически архитектор обычно сидит и рисует квадратики на листе.
— Если честно, то я считал и буду считать, что Скриптовый!!! PHP не создан для тяжелых сложных архитектур постоянно весящих в памяти, на нем из-за его типизации приходится очень аккуратно кодить, малыми кусками. Для тяжести и жести мне кажется Java или C# самое то + ультимейтная студия с UML. А так сам PHP чрезвычайно легок и быстр для работы с текстами, выборками БД, любыми скриптовыми обработками (то есть алгоритмы на нем приятно делать, компилятор написать например можно теоретически но не сложную систему, ввиду скриптовости и динам. типизацией), etc. Но обычно для сайтов применяется и все, что еже с ними ибо на нем можно быстро написать, а потом, если есть желание наприсать ввиде C++ либы, увелича скорость до теоретически максимальной (так делается на любых крапных проектах)
Коммент из серии «оценка».
Статья хорошая, ваш код понравился. Не скрою впервые увидел неймспейсы, спасибо буду думать куда можно это применить.
Абстрактный синглтон нерабочий. Совсем нерабочий. Никак нерабочий. Нерабочий начиная с обратного слеша перед get_called_class(), написанием static:: вместо self:: и заканчивая тем, что в абстрактном классе никак сделать new self() – на то он и абстрактный класс.
Если Вам нравится FORTH балуйтесь с Rebol, где есть настоящее ядро Форт-машины, всё маленькое и крутое.
Не представляю как любя такие вещи, как FORTH, можно не испытывать отвращения к таким поделиям как его интерпретатор на PHP.
Многие пытались доказать, что PHP нечто большее, чем инструмент изначально разработанный для плевания в веб разметкой и клей для различных библиотек.
Так появились ущербные с рождения проекты ActivePHP, PHP-GTK и wxPHP.
Покажите мне задачу, за пределами веба, где был оправданно использован PHP?
Не представляю как любя такие вещи, как FORTH, можно не испытывать отвращения к таким поделиям как его интерпретатор на PHP.
Многие пытались доказать, что PHP нечто большее, чем инструмент изначально разработанный для плевания в веб разметкой и клей для различных библиотек.
Так появились ущербные с рождения проекты ActivePHP, PHP-GTK и wxPHP.
Покажите мне задачу, за пределами веба, где был оправданно использован PHP?
>> Покажите мне задачу
и тут же
>> ущербные с рождения проекты
>> плевания в веб разметкой
Ну и зачем Вам что-то показывать и доказывать? Вы уже свой путь выбрали, удачи.
и тут же
>> ущербные с рождения проекты
>> плевания в веб разметкой
Ну и зачем Вам что-то показывать и доказывать? Вы уже свой путь выбрали, удачи.
Я этот путь прошёл
До версии 5.2.1 из PHP нельзя было без глюков работать с базовыми
stdin
stdout
stderr
может быть помните разрекламированный в книге Котерова (вроде его) интересный трюк с использованием своего, написанного на php хендлера под apache,
когда в качестве хендлера указывается не cgi php, а скрипт на php
начинающийся с
#!/path/to/php-cli
#!/path/to/php
а оказывается не мог PHP в таком режиме не падая работать с базовыми потоками ввода вывода,
о чём тут дальше говорить
До версии 5.2.1 из PHP нельзя было без глюков работать с базовыми
stdin
stdout
stderr
может быть помните разрекламированный в книге Котерова (вроде его) интересный трюк с использованием своего, написанного на php хендлера под apache,
когда в качестве хендлера указывается не cgi php, а скрипт на php
начинающийся с
#!/path/to/php-cli
#!/path/to/php
а оказывается не мог PHP в таком режиме не падая работать с базовыми потоками ввода вывода,
о чём тут дальше говорить
Интранет сервисы, не всегда вебовские и не плюющие в веб разметкой сервисы.
Отчеты удобно генерить в разных форматах из базы данных.
Отчеты удобно генерить в разных форматах из базы данных.
под вебовскими подразумевалось всё, что передаётся через http
ну отчеты у меня например в консоле генерятся, часть на php, часть на perl'е старая, и ничего, удобно и быстре менять местами чем в том же Crystal Reports.
Сервис погоды у меня не по http отдаёт, обычным сокетом, крутится тоже на php.
Сборщик twitter сообщений периодически запускается через cron, тоже на php, новый на ruby уже почти готов, но это лишь потому, что и фронт сайта на rails будет.
В чем проблема-то, не только сайты уже давно и тебе сокеты пожалуйста и cli и mdaemon в подарок. Лишь бы с умом прикладывать голову, а инструмент плохим не бывает, задача может быть не подходящая, но главное решение в любом случае и компромис.
Сервис погоды у меня не по http отдаёт, обычным сокетом, крутится тоже на php.
Сборщик twitter сообщений периодически запускается через cron, тоже на php, новый на ruby уже почти готов, но это лишь потому, что и фронт сайта на rails будет.
В чем проблема-то, не только сайты уже давно и тебе сокеты пожалуйста и cli и mdaemon в подарок. Лишь бы с умом прикладывать голову, а инструмент плохим не бывает, задача может быть не подходящая, но главное решение в любом случае и компромис.
Ни с чем из перечисленного не спорю,
только есть один большой нюанс, по большей части приложения написанные на php имеют короткий цикл выполнения,
если вам надо написать нетривиальное приложение, которое должно запуститься и потом год работать без перезапуска, то лучше это сделать например на Python'е,
потому что в основных механизмах применения PHP
как модуля или как fast-cgi предусмотрен периодический перезапуск системного процесса, во избежании того что откуда-нибудь да натечёт большая лужа, дырки откуда течёт затыкают, но при таком коротком интервале времени, которое обычно отводится на выполнение PHP процессу (даже как модулю сервера) не всегда видно что стало капать и откуда
В Python'е же просто в силу большей его применяемости для долгоиграющих приложений, такие проблемы заметнее и оттого устраняются вероятнее.
только есть один большой нюанс, по большей части приложения написанные на php имеют короткий цикл выполнения,
если вам надо написать нетривиальное приложение, которое должно запуститься и потом год работать без перезапуска, то лучше это сделать например на Python'е,
потому что в основных механизмах применения PHP
как модуля или как fast-cgi предусмотрен периодический перезапуск системного процесса, во избежании того что откуда-нибудь да натечёт большая лужа, дырки откуда течёт затыкают, но при таком коротком интервале времени, которое обычно отводится на выполнение PHP процессу (даже как модулю сервера) не всегда видно что стало капать и откуда
В Python'е же просто в силу большей его применяемости для долгоиграющих приложений, такие проблемы заметнее и оттого устраняются вероятнее.
Согласитесь, что это проблема не языка, а его реализации?
У PHP не было и нет устоявшегося дизайна языка, у него есть только реализация, в которой время от времени появляются фичи, ООП добавлено именно как фича или скорее набор фич, этот набор фич со временем меняется и растёт, но по отношению к языку остаётся вторичным
Ну архитектура у языка плохая, не поспоришь с этим, начали с ориентира плохого, но простого, растут как могут, от потребностей.
Но 5.3 это уже не тот совсем язык как привыкли например в 5.1 даже видеть.
ООП же не панацея и не серебрянная пуля, в ряде случаев даже лишнего будет.
С выходом 6ой, если внесут Unicode, избавятся от обратной совместимости с кучей старого процедурного мусора и перенесут в ООП (как сделали с DateTime) то язык получит еще больше плюсов, будет уже почти другой язык.
Но 5.3 это уже не тот совсем язык как привыкли например в 5.1 даже видеть.
ООП же не панацея и не серебрянная пуля, в ряде случаев даже лишнего будет.
С выходом 6ой, если внесут Unicode, избавятся от обратной совместимости с кучей старого процедурного мусора и перенесут в ООП (как сделали с DateTime) то язык получит еще больше плюсов, будет уже почти другой язык.
>>Но 5.3 это уже не тот совсем язык как привыкли например в 5.1 даже видеть.
+1
Именно поэтому я всегда на собеседовании спрашиваю про 5.3 Этот вопрос — самый важный детектор.
+1
Именно поэтому я всегда на собеседовании спрашиваю про 5.3 Этот вопрос — самый важный детектор.
Не хочу вас расстраивать, человек(один) который переводил PHP на Unicode благополучно забил на это дело.
Так что 6ка еще не скоро.
Так что 6ка еще не скоро.
Может это и хорошо, что короткий, не будет при блокировки приложения лока самого сервера.
В прошлом висел у меня ICQ бот на PHP, месяцами утечек не было, может это при каких-то условиях и версиях утечки были. Мне кажется в PHP всё есть для нормальной работы в режиме демона, интерпретатор написать бы нормальный его или как уже я слышал есть вполне решения пересборки кода в иные платвормы hip-hop, JVM и т.п.
Про Python рассуждать не могу в силу так как знаком поверхностно с языком и предпочитаю ему Perl и Ruby.
В прошлом висел у меня ICQ бот на PHP, месяцами утечек не было, может это при каких-то условиях и версиях утечки были. Мне кажется в PHP всё есть для нормальной работы в режиме демона, интерпретатор написать бы нормальный его или как уже я слышал есть вполне решения пересборки кода в иные платвормы hip-hop, JVM и т.п.
Про Python рассуждать не могу в силу так как знаком поверхностно с языком и предпочитаю ему Perl и Ruby.
Наиболее известная причина утечек — циклические ссылки. Относительно недавно только сборщик мусора поправили, чтобы мог корректно работать с ними. Остальные утечки, имхо, на том же уровне, что и в других языках/библиотеках, написанных на C/C++/asm, то есть баги реализации «кирпичиков», а не архитектуры в целом.
Ну в 5.3 такой фигни уже нету)
Вроде в 5.3.0 добавили собственно сборщик мусора, а в 5.3.3 поправили его баг с циклическими ссылками.
В чейнджлоге — не нашел. Насколько я помню, какой-никакой сборщик мусора был в php и до 5.3, но именно в 5.3 его сделали нормальным, а не «лишь бы был».
bugs.php.net/48781 — Это?
Version 5.3.3
22-July-2010
…
Fixed bug #48781 (Cyclical garbage collector memory leak). (Dmitry)
…
Version 5.3.0
30-June-2009
…
Improved PHP runtime speed and memory usage:
…
Added garbage collector. (David Wang, Dmitry).
php.net/ChangeLog-5.php#5.3.3
Что-там было до этого не у кого, видимо, язык не поворачивался назвать сборщиком мусора :)
Да, забыл про эту причину, спасибо.
В целом если писать аккуратно и знать о причинах, можно писать и без утечек.
Имея эдакий use strict; и всегда зная о my из Perl'а как хорошая школа может послужить и PHP кодеру.
В целом если писать аккуратно и знать о причинах, можно писать и без утечек.
Имея эдакий use strict; и всегда зная о my из Perl'а как хорошая школа может послужить и PHP кодеру.
Зачем работать со стеком (доставать аргументы для операторов) в главном цикле? По идее, функция оператора "+" должна выглядеть как-то так:
Да и реализация словаря с указанием количества используемых слов в стеке явно не универсальна — что будем делать со словами, которые могут брать со стэка разное количество слов?
Да и стэка, кажется, нужно минимум два — данных и команд. Хотя, может, и ошибаюсь тут, давно ту книжку читал :) По-моему, начинать реализовывать Forth-машину нужно со слова ':', реализовав его словарь (кстати, он же кажется тоже не один может быть) у нас будет практически готов.
function () {
$a = Stack::pop();
$b = Stack::pop();
Stack::push($a+$b);
}Да и реализация словаря с указанием количества используемых слов в стеке явно не универсальна — что будем делать со словами, которые могут брать со стэка разное количество слов?
Да и стэка, кажется, нужно минимум два — данных и команд. Хотя, может, и ошибаюсь тут, давно ту книжку читал :) По-моему, начинать реализовывать Forth-машину нужно со слова ':', реализовав его словарь (кстати, он же кажется тоже не один может быть) у нас будет практически готов.
Ваша реализация слова предполагает, что слово должно знать о существовании стека. Не думаю, что это хорошо, слово — это просто функция, с аргументами и возвращаемым значением. Стеком должен оперировать executor все-таки.
Не просто должно, а обязано. Forth — это стек, слов не работающих с ним чуть меньше, чем ничего :) Слова, которые берут и кладут в стэк разное количество слов, в зависимости от, например, слова, которое лежит на самом верху, вполне реальны, та же обработка массивов — наверху длина, дальше элементы. Как будете реализовать слово, считающее сумму элементов, вводить в «палача» препроцессор, который для некоторых слов будет вытаскивать переменное число слов из стека? К тому же классическое слово, это последовательность вызова других слов и чисел, что в вашем словаре пока не вижу как реализовывать… Или на лету функции создавать?
Стэка определённо надо два.
Для чего же нужен второй, не подскажете?
А нет, всё правильно, достаточно одного. С математикой просто не разобрался. Сейчас вроде понял.
Стэк вызовов и стэк данных, не? Хотя, может я зациклен на известных мне реализациях Forth, которые почему-то все были на ассемблере :)
Стек он один, он же Стек. В классическом Форте, разумеется.
А для команд есть очередь.
А для команд есть очередь.
Не нравится мне ваши очередь и словарь чем-то интуитивно :) Что-то очень важное упущено, по-моему, что в дальнейшем потребует серьезной переделки. Один пример я уже привёл — переменное количество слов в стеке на входе. Но и это ещё не всё :)
Понял, в качестве стека возвратов вы используете (вернее будете, наверное, использовать) стек возвратов PHP.
Понял, в качестве стека возвратов вы используете (вернее будете, наверное, использовать) стек возвратов PHP.
В классическом форте как минимум 2 стека — стек данных и стек возвратов. Исключение — форт машины, которые на основе подпрограммного кода, Но любый варианты шитого кода (прямой, косвенный и тд), то есть подавляющее большинство форт машин, требую явного стека возвратов.
Вы с ним не столкнулись, потому что Ваша реализация не умеет определять слова. Как понадобится выполнять определенные пользователем слова, так и у вас второй стек появится.
То, что вы написали и не форт, строго говоря.
Вы с ним не столкнулись, потому что Ваша реализация не умеет определять слова. Как понадобится выполнять определенные пользователем слова, так и у вас второй стек появится.
То, что вы написали и не форт, строго говоря.
Не Форт, конечно. Просто модель. С возможностью дальнейшего развития, если это потребуется.
Опачки… А там чуть повыше как раз был спор по поводу «Нужен ли стек в виде Singleton»
habrahabr.ru/blogs/php/114666/#comment_3702077
Выходит что и правда категорически не нужен.
Не призываю к холивару, просто тоже считаю что в PHP как-то уж очень любят Singleton-ы. Наверное старая любовь к глобальным переменным так перевоплотилась.
habrahabr.ru/blogs/php/114666/#comment_3702077
Выходит что и правда категорически не нужен.
Не призываю к холивару, просто тоже считаю что в PHP как-то уж очень любят Singleton-ы. Наверное старая любовь к глобальным переменным так перевоплотилась.
А, понял о чем Вы.
Нет, так далеко я не заглядывал, я намеренно ограничил себя самыми простейшими словами. Это не Форт-машина даже, а некая ее модель.
Нет, так далеко я не заглядывал, я намеренно ограничил себя самыми простейшими словами. Это не Форт-машина даже, а некая ее модель.
Понятно :) Предупреждать надо, а то я чуть не зарылся в дебри выискивая ошибки. Но парочку уже нашёл даже по вики — допускаются дублирование слов в словаре (поиск идёт с конца) и сначала проверяется есть ли слово, а уж потом можно ли интерпретировать токен как число (слова «0», «1», «2» часто определяют на целевом языке, например на ассемблере, для увеличения быстродействия).
> Во-первых они совершенно не интересуются развитием языка, на котором пишут, и вопрос «А что нового в PHP 5.3» ставит их в тупик
Наблюдать за развитием PHP все равно, что наблюдать за броуновским движением.
Наблюдать за развитием PHP все равно, что наблюдать за броуновским движением.
спасибо за фразу, возьму на заметку и буду троллить ей пхпшников.
Нас, естественно, сразу заминусовали. Хотя даже быстрый взгляд на историю развития только подтвержадет сказанное мной.
Потому что только в РНР возможна ситуация, когда переход между минорными версиями (5.2.x -> 5.3.x) приносит фич больше, чем любой переход между мажорными версиями (что 4.x -> 5.x, что 5.x -> 6.x)
Потому что только в РНР возможна ситуация, когда переход между минорными версиями (5.2.x -> 5.3.x) приносит фич больше, чем любой переход между мажорными версиями (что 4.x -> 5.x, что 5.x -> 6.x)
Это единственное исключение, версия 5.3 — это недоношенная 6-ая, все фичи 6-ой версии на тот момент успеть сделать было сложно, а сообщество уже страдало в ожидании, потому как многие нововведения — наболевшие, как например пространства имен, нормальные анонимные функции, GOTO — и тогда собственно и выпустили версию 5.3, с половиной фич 6-ой, тех что были уже готовы, отсрочив тем самым выпуск 6-ой версии. И пхпшники целы, и зендовцы сыты :)
> Это единственное исключение, версия 5.3 — это недоношенная 6-ая
Да нет, не единственное. Бардак в стандартной библиотеке, три или четыре способа подключения к MySQL и многое многое другое, что лень даже упоминать
> потому как многие нововведения — наболевшие
это все отмазки :) это могли нормально назвать 6-й версией и не париться. Потому что что будет в PHP 6 никто до сих пор не знает. Да а чем говорить, у PHP до сих пор даже roadmap'а или какой-либо осмысленной стратегии развития нет.
как иллюстрация:
5.3.0 — Native closures
6.0 — closure $this support
хотя понятно, что поддержка $this в замыканиях — это фича для минорной версии, а не для неизвестно когда выходящей мажорной.
и так — на каждом шагу
З.Ы. Я сам — программист на РНР, так что эта «боль такая боль» идет из глубины сердца :)
Да нет, не единственное. Бардак в стандартной библиотеке, три или четыре способа подключения к MySQL и многое многое другое, что лень даже упоминать
> потому как многие нововведения — наболевшие
это все отмазки :) это могли нормально назвать 6-й версией и не париться. Потому что что будет в PHP 6 никто до сих пор не знает. Да а чем говорить, у PHP до сих пор даже roadmap'а или какой-либо осмысленной стратегии развития нет.
как иллюстрация:
5.3.0 — Native closures
6.0 — closure $this support
хотя понятно, что поддержка $this в замыканиях — это фича для минорной версии, а не для неизвестно когда выходящей мажорной.
и так — на каждом шагу
З.Ы. Я сам — программист на РНР, так что эта «боль такая боль» идет из глубины сердца :)
А вы случайно не забыли стек R, декларацию новых слов и макроподстановки? А то получился не форт, а овердизайнед
RPN-калькулятор.
RPN-калькулятор.
Вы серьезно думаете, что за 3 часа я бы успел это все реализовать, протестировать и написать статью на хабр?
На PHP — вероятно, нет. На правильно выбранных инструментах — да.
Думаю, можно и в два уложиться. Это говорит о том, что надо выбирать инструменты под задачу, а не пытаться забить все гвозди мира отверткой.
Думаю, можно и в два уложиться. Это говорит о том, что надо выбирать инструменты под задачу, а не пытаться забить все гвозди мира отверткой.
Форт и интересен тем, что позволяет создать минимальную Форт-систему из ничего за очень короткое время. Под неизвестную (но не слишком извращённую) архитектуру она пишется за пару ночей.
Эх, php-php как же это уродливо выглядит:
$args = \array_slice(..)Ради контекстной независимости, очевидно.
ну я как бы про то, что символ выбран неудачно, в этих C++/С# чудесное "::", в Java ".". Нет ну честное слово это выглядит лучше
food::soup и java.lang.String чем
\FORTH\EXCEPTIONS\SYSTEM\NamespaceIsWrong();И "::" и "." уже были заняты как бы.
ну как бы они и в Java и в C++ тоже как бы заняты "::" для доступа к статическим методам/свойствам. "." для аналогичных целей в Java (для дотупа к обычным методам/свойсвам тоже)
Вы немного несравнимое сравниваете.
Никогда не думали, почему в PHP числа складываются "+", а строки конкатенируются "."? Зачем два разных оператора, если, например, JS обходится одним "+"?
Никогда не думали, почему в PHP числа складываются "+", а строки конкатенируются "."? Зачем два разных оператора, если, например, JS обходится одним "+"?
сравнимое сравниваем. емнип, символ \ был выбран, потому что лень было возиться с парсером.
То есть ответ «нет, не думал».
Неверный вывод.
Для слаботипизированного языка просто обязательно иметь два разных символа для конкатенации строк и складывания чисел. Это — очень грамотное решение со стороны разработчиков РНР.
К вопросу о выборе символа для namespace'ов это не имеет отношения.
Для слаботипизированного языка просто обязательно иметь два разных символа для конкатенации строк и складывания чисел. Это — очень грамотное решение со стороны разработчиков РНР.
К вопросу о выборе символа для namespace'ов это не имеет отношения.
Ну и ровно также нужно иметь два разных символа для обозначения статического метода или свойства и неймспейса.
Парсер-то один. Любое его усложнение — это зло, пусть лучше кривой символ, к нему привыкнуть можно, да и IDE помогут, чем лишние миллисекунды работы парсера, пытающегося определить контекст оператора.
Парсер-то один. Любое его усложнение — это зло, пусть лучше кривой символ, к нему привыкнуть можно, да и IDE помогут, чем лишние миллисекунды работы парсера, пытающегося определить контекст оператора.
> Ну и ровно также нужно иметь два разных символа для обозначения статического метода или свойства и неймспейса.
> Ну и ровно также нужно иметь два разных символа для обозначения статического метода или свойства и неймспейса.
Не ровно так же. Знак для неймпейса всего лишь контекстно-зависимый, а не типозависимый
> чем лишние миллисекунды работы парсера, пытающегося определить контекст оператора.
а ничего, что символ \ уже в PHP используется?
Не ровно так же. Знак для неймпейса всего лишь контекстно-зависимый, а не типозависимый
> чем лишние миллисекунды работы парсера, пытающегося определить контекст оператора.
а ничего, что символ \ уже в PHP используется?
Везде есть свои недостатки. Я думаю в этом есть определенная вина тех, кто стоит у разработки ядра PHP, они не всегда принимают удачные решения. Не думаю, что аргумент «это сложно и мы делать не будем, а лучше прилепим что-нибудь другое», достаточно весомый (я не знаю, чем они руководствовались, когда решили что "::" или "." не подходит для namespace).Ладно пойду дальше работать, всё равно "\" для namespace это уродливо.
можно просто писать array_slice() =) А вообще мне тоже сначала не нравилось, но пописав с полгода, привык, и сейчас мне даже нравится.
Мне кажется, народ недостаточно яростно плюсует этот топик. Да, в комментариях не меньше интересного, чем в самом посте. Но ведь эти комментарии надо было спровоцировать!
> Все ошибки обрабатываем исключениями,
> Пусть код зияет большими пробелами (например мы нигде пока не ловим исключения
а в результате такой практики появятся белые страницы и гигатонны какашек в еррорлогах
> Пусть код зияет большими пробелами (например мы нигде пока не ловим исключения
а в результате такой практики появятся белые страницы и гигатонны какашек в еррорлогах
> Каждое имя класса должно однозначно указывать на его место в файловой системе
> Один класс — один файл
Рискну порекомендовать добавить пункт «Гибкая и настраиваемая XML-конфигурация» в список архитектурных решений. и почему вы не используете Spring.Php Framework?
> Один класс — один файл
Рискну порекомендовать добавить пункт «Гибкая и настраиваемая XML-конфигурация» в список архитектурных решений. и почему вы не используете Spring.Php Framework?
> Используем все современные возможности языка:
ВЫ НЕ ИСПОЛЬЗОВАЛИ ФУНКЦИЮ GOTO, ЗНАЧИТ, ВАША АРХИТЕКТУРА ГОВНО
ВЫ НЕ ИСПОЛЬЗОВАЛИ ФУНКЦИЮ GOTO, ЗНАЧИТ, ВАША АРХИТЕКТУРА ГОВНО
В тонкости не вникал, но скорее всего конструкцию
правильнее заменить на
при условии, что по ходу цикла значение, возвращаемое
Чисто из соображений производительности. В первом случае вызов функции на каждой итерации, во втором — один раз при инициализации цикла.
for ( $i = 1; $i <= $word->getStackPopCount(); $i++ )
$args[] = $this->stack->pop();правильнее заменить на
for ( $i = 1, $sp_count=$word->getStackPopCount(); $i <= $sp_count; $i++ )
$args[] = $this->stack->pop();при условии, что по ходу цикла значение, возвращаемое
$word->getStackPopCount() не меняется (в 99% случаев это именно так)Чисто из соображений производительности. В первом случае вызов функции на каждой итерации, во втором — один раз при инициализации цикла.
PHP — достойный язык, который покрывает 99,9% желаемого программистом. Приведите пример того, что нельзя реализовать на PHP. Может что-то скажете про хайлод проекты, что якобы он не предназначен для этого? Что бы не быть голословным, первое, что в памяти: Facebook, Vkontakte, Fotostrana. Facebook-у понятное дело пришлось искать выход, что бы не переписывать тонны кода, естественно, это не целесообразно, за тем и был изобретён hip-hop. Не вижу ни одного логического обоснования тому, что php должен умереть! Да ёлки-палки, не хочешь php, пиши подо что руки заточены. На в кус и цвет, как говориться… Я пишу на PHP уже более 11 лет, начал с его «родителя» Perl, за это время попробовал и Ruby и Python. Откровенно говоря, не смог найти ему замену под web. Мил он мне и всё тут!
Прощу прощение за то, что ввязался в холивар… Не мог не высказаться в защиту PHP!
А еще wikipedia.org, flickr.com и много других… последний конечно лапша-код, но работает же!
Реализовать можно многое (если не всё) другой вопрос что некоторые вещи реализовать глупо. Если бы я увидел человека реализующего на РНР например web-server (а такие были) я бы просто решил что у человека слишком много свободного времени, и в решении реальных задач у него опыта нет.
Для РНР программиста я считаю хорошим признаком владение другими языками (не важно с Си в школе баловался, или на Perl писал хотя бы даже простенькие скриптики типа гостевых книг) это показывает способность человека не привязываться к одному языку.
(Из личного наблюдения, люди знающие только РНР, чаще всего знают его весьма плохо, ибо голова забита древними статьями класса «выучи РНР3 за час», редко встречаются те кто читали хотя бы Котерова. В случаях когда люди знают разные языки, шансы наткнуться на хорошего специалиста чуть выше.)
Для РНР программиста я считаю хорошим признаком владение другими языками (не важно с Си в школе баловался, или на Perl писал хотя бы даже простенькие скриптики типа гостевых книг) это показывает способность человека не привязываться к одному языку.
(Из личного наблюдения, люди знающие только РНР, чаще всего знают его весьма плохо, ибо голова забита древними статьями класса «выучи РНР3 за час», редко встречаются те кто читали хотя бы Котерова. В случаях когда люди знают разные языки, шансы наткнуться на хорошего специалиста чуть выше.)
Web-server? Смотря для каких нужд. На PHP реализовать его не составит труда вообще, немного строчек кода и готово, особенно когда есть снипеты и личные наработки. Если у вас высокие требования — используйте Apache, если ещё выше — nginx. Надо уметь пользоваться тем, что уже есть и не изобретать велосипед, если стоит кастомная/нестандартная задача — учись допиливать, а любители писать всё своё и с нуля — найдут время. Никто не говорит, что владение несколькими языками плохо и что зацикливаться на одном php клёво. Всё зависит от конкретных задач и требований (клиента). Сколько людей — столько мнений!
Насчет фейсбука, с quora.com, от разработчика Facebook c 2005 года (по нынешнее время):
перевод:
С другой стороны, от другого разработчика Facebook:
перевод:
Ironically, Facebook probably contains the largest concentration of «PHP experts who hate PHP» anywhere, since many of the engineers have (1) become experts in the idiosyncrasies of PHP and (2) hate them because they are also great engineers who prefer more elegant languages. My observation is that anyone who learns PHP really well discovers how poorly-designed a language it is and tends to develop a loathing for it.
перевод:
По иронии судьбы, в Facebook, вероятно, самая большая концентрация «PHP-экспертов, ненавидящих PHP», т.к. многие из разработчиков (1) стали экспертами по странностям PHP и (2) терпеть их не могут, т.к. они также являются отличными раработчиками, предпочитающими другие, более элегантные языки. Мое наблюдение: каждый, кто изучил PHP по-настоящему хорошо, осознает, как этот язык плохо разработан, и имеет тенденцию к тому, чтобы к PHP начать относиться с отвращением.
С другой стороны, от другого разработчика Facebook:
Do I enjoy programming in PHP, per se? No. Do I enjoy working on Facebook's PHP code base? Yes.
перевод:
Нравится ли мне программирование на PHP само по себе? Нет. Нравится ли мне работа над PHP-кодом в Facebook? Да.
Хе-хе, или это самообман какой-то или синдром, под названием «Пендос». Они там давно с катушек съехали все, уже не знают, что хотят и что попробовать ещё. Но в любом случае, интересный факт. kmike, спасибо, поразмышляю над этим!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заметки об архитектуре или Интерпретатор Forth на PHP 5.3