Первый релиз фреймворка SolarPHP

> вы имеете ввиду наколенные поделки?
Судя по вашим словам, да.

Так на них никто завязываться не будет

А зачем завязываться? Сделать возможность и небольшой интерфейс для прикручивания к абстрактной реализации FastCGI. Если кому-то приспичит - он прикрутит.
А так приходится перелопачивать фреймворк из-за того, что этот набор быдлокода завязан на устаревшем CGI.

Кто-то хотел кажется, что-то такое в веб-девелопметсе.

В модельном ряду велосипедов пополнение?

Очень на то похоже.

скаффолдинг есть?

Согласно мануалу таблицы нужно руками создавать: http://www.solarphp.com/manual/blog-demo.model . Нельзя описать модель и автоматом создать таблицы. Не удобно. А заявлять о легковесности фрэймворка без работы с БД почти нет смысла.

По мне так joomla — это АдЪ. В MODx борьбы с CMS гораздо меньше.

> Согласно мануалу таблицы нужно руками создавать

Ты думаешь пхпшников это волнует? Главное чтоб картинка красивая была в шапке и видео уроки на русском.

>Реализации fastcgi-сервера для php уже есть

fastcgi-сервер для PHP - есть. fastcgi-php-приложений - нет. Это разные вещи.

Первое указывает на то, что PHP-сервер загружен, но при каждой загрузке PHP-приложения, оно грузится с нуля со всеми инклудами. Можно только закешировать байткод.

В итоге решения, всё равно, получаются по скорости сравнимые с тем же Django, но это - fastcgi-php, но не fastcgi-приложения.

>> Согласно мануалу таблицы нужно руками создавать

Ты думаешь пхпшников это волнует?

Среднего PHP-шника, как раз, это первое что волнует. Сегодня нормальное PHP-приложение - это обращение к /install.php и дальше серия нажатий «Дальше».

>>Зачем эта новость пропущена на главную? Настолько ли этот фреймворк значителен?

а вы, батенька, викитолерантен, что вам значимость так важна?

Согласно мануалу таблицы нужно руками создавать

и что, быдлокодеры sql никак освоить не могут?

Возможно, у меня кривая терминология, но я имел ввиду решение именно без перезапуска скриптов. Про то, что первое давно существует, я в курсе.

>Возможно, у меня кривая терминология, но я имел ввиду решение именно без перезапуска скриптов.

Про это я и написал, что таких решений на практике нет. И во многом, действительно, от того, что у PHP крайне примитивный и текучий менеджер памяти. Для разовых запусков это не страшно, а вот висеть долго и отдавать много запросов - память начнёт утекать быстро.

...

Правда, есть ещё Quercus, там в качестве менеджера памяти используется GC от JVM, но запускать PHP-сервер на Java - не очень красивая идея ;)

Кстати, раз уж теперь совсем очевидно, что php не очень пригоден для высокозагруженных приложений, может ли кто-нибудь объяснить, почему даже в этой сфере он частенько используется?

Ruby или Python тоже подходят для высокозагруженных приложений хуже, чем та же Java. А Java хуже подходит, чем Си++. Но все описанные платформы используются весьма часто.

Обычный размен скорости на удобство и/или скорость/простоту раработки :)

> Работают, но пробелы предпочтительнее.

_Кому_ предпочтительнее? Мне - я сам решу как-нибудь. И так куча ограничений из-за значимых пробелов, еще будут указывать сколько именно и каких? Нафиг.

Да по-моему проблемы не в этом только. Сами идиомы пхп противоречят fast-cgi. Из того, что первое приходит на ум, - это конечно глобальные переменные реквеста: всякие там $_POST,$_GET,$_FILES. Даже не смотря на то, что последнее время все больше и больше юзают MVC, глобальные переменные все равно встречаются в любых местах системы. Вот как бы и смысла особого юзать fast-cgi нет. И, на сколько мне известно, в 5.3 серьезно переделали сборщик мусора. Ну да и черт с ним! Пхп нужен для грязного, быстрого программирования сайтов для малого бизнеса.

>Даже не смотря на то, что последнее время все больше и больше юзают MVC, глобальные переменные все равно встречаются в любых местах системы.

Это никак не связано с PHP. Скажем, в моём фреймворке использование глобальных переменных крайне мало и применяется в строго фиксированных местах, без расползания по коду. И используется исключительно на системном уровне самого фреймворка. На прикладном уровне глобальных переменных нет вообще нигде. Т.е. за весь процесс написания сложного сайта, на полную катушку использующего PHP без всяких изощрений можно легко избежать использования глобальных переменных вообще.

Так что дело тут явно не в языке, а в практике :)

И, на сколько мне известно, в 5.3 серьезно переделали сборщик мусора.

Посмотрим, когда появится на массовых хостингах.

>Это никак не связано с PHP. Скажем, в моём фреймворке использование глобальных переменных крайне мало и применяется в строго фиксированных местах, без расползания по коду. И используется исключительно на системном уровне самого фреймворка. На прикладном уровне глобальных переменных нет вообще нигде. Т.е. за весь процесс написания сложного сайта, на полную катушку использующего PHP без всяких изощрений можно легко избежать использования глобальных переменных вообще.

Связано это с пхп. Это одна из его идиом. Коротко так: fast cgi для старых сайтов, где используются глобальные переменные, пользы никакой не принесет; писать сайты без глобальных переменных и сделать все-таки нормальный fast cgi, — забить на одну из идиом пхп. Последнее значит, в какой-то мере, забить на пхп и отказаться от его идиом. Отказаться ровно от того почему пхп это пхп и почему пхп популрен и тд и тп. С точки зрения разработчиков интерпретатора — это точно не популисткая мера.

Все это было бы хорошо для идеального мира и в пхп давно-давно сломали бы обыратную совместимость с откровенно старым быдловозможностями(быдлоуступками).

Больше всего в пхп сейчас парит не подходящая для новых ооп-фич стандартная библиотека. Лучше бы ей кто занялся. А еще лучше — даешь полностью ООП. + лямбды как во всех нормальных языках, с возможностью ссылки на $this. По поводу ооп — по-моему все-таки к этому и идет. Интересно, смогут ли разработчики найти компромис между простотой языка для начинающих и пересаживанием пхп на ооп-рельсы без говна.

>писать сайты без глобальных переменных и сделать все-таки нормальный fast cgi, — забить на одну из идиом пхп

Ну я же пишу :) Не напрягаясь и не испытывая нужды в этом. При чём не из каких-то идеологических соображений, а исключительно из соображений удобства. Получается, что никакая это не идиома PHP. А особенности некоторых программистов.

Все это было бы хорошо для идеального мира и в пхп давно-давно сломали бы обыратную совместимость с откровенно старым быдловозможностями(быдлоуступками).

Так не привыкать же. register_globals, вон, спокойно сломали в своё время :)

Больше всего в пхп сейчас парит не подходящая для новых ооп-фич стандартная библиотека.

А кто заставляет ею пользоваться, если к ней такая жгучая нелюбовь? :) Понятно, что в десятистрочном автономном скриптике вопрос использования стандартной библиотеки решается однозначно, а вот в любом крупном проекте это сказывается намного меньше. Там основная работа идёт уже с методами самого проекта.

с возможностью ссылки на $this

Так сейчас итак по умолчанию все присваивания объектов работают через ссылки. А $x = $this скопирует ссылку на текущий объект.

Интересно, смогут ли разработчики найти компромис между простотой языка для начинающих и пересаживанием пхп на ооп-рельсы без говна.

Новые функции очень часто работают сразу в двух стилях - и функциональном, и объектном. Например, http://ru2.php.net/sqlite_query

Подход, равно популярный и в ряде других языков.

>Ну я же пишу :) Не напрягаясь и не испытывая нужды в этом. При чём не из каких-то идеологических соображений, а исключительно из соображений удобства. Получается, что никакая это не идиома PHP. А особенности некоторых программистов.

и я пишу! Но что это меняет? Ни-че-го. Быдлокодерам надо глобальные переменные, иначе зачем им пхп? можно же взять жабу.Вот я про что. fast cgi в пхп никому не интересно. Из-за fcgi появится еще больше нестыковок.

А кто заставляет ею пользоваться, если к ней такая жгучая нелюбовь? :) Понятно, что в десятистрочном автономном скриптике вопрос использования стандартной библиотеки решается однозначно, а вот в любом крупном проекте это сказывается намного меньше. Там основная работа идёт уже с методами самого проекта.

Все равно это не хорошо.

Так сейчас итак по умолчанию все присваивания объектов работают через ссылки. А $x = $this скопирует ссылку на текущий объект.

Я имел в виду замыкания: сейчас нельзя сделать function() use($this) {};
Возможен только грязный трюк
$me = $this;
function() use($me) {...};
Но это плохо! - Приходится свойства делать публичными.

Новые функции очень часто работают сразу в двух стилях - и функциональном, и объектном. Например, http://ru2.php.net/sqlite_query

Это как раз ооп с говном. Если функцию потребуются переопределить, то у Вас нету никаких шансов.
Да и даже не все функции работают с объектами: Над SplFixedArray можно выполнять только то, что определено методами в этом классе. Как бы сделать массив фиксированой длинны — это отличная идея.Но вот, к сожалению, сам массив и SplFixedArray никак не взаимозаменяемы в коде.