Ща начнется война, если у воинствующих сторон остались силы, или что важнее, желание, спорить на эту тему.

facebook и vkontakte за большие проекты пойдут?

2й сайт по посещаемости в мире
Самая высокая ЗП у программистов ФейсБука....
ммм....налей мне пол стаканчика таких "капелек"

Я говорил не про личное отношение, а только лишь про то, что я не знаком с этим ресурсом.
К тому же, всё равно уверен, что все "тяжелые" операции даже там, выполняются на java или C более чем на 100%.
Пусть не отдельным скриптом как самостоятельным WEB приложением, а просто обращением.

Я не стал влезать в дискуссию twin'а и linker'а по этому поводу, но тут скажу - не имеет значения в чем разбираться в процедурке или в ооп. Ты всё равно будешь сидеть и анализировать код (если конечно доков нет), как бы он написан небыл. Однако в случае ООП есть четкая структура кода, разрешение зависимостей, и ещё много всяких плюшек, которых нет в процедурке (но которые при желании конечно можно накостылить).
Ещё, естественно, нужно четко понимать что есть ООП, а что есть "возможность написать класс", и я не совсем пойму против чего UnWind, а?

откуда взял ???

Ты меня не понял, защитник животных. Ты опять смешал классы и ООП. В контексте нашей нашей беседы (и для php) разница в этом есть. Ты можешь написать своё приложение на классах, а можешь применить объектно ориентированный подход. Так против чего ты?

Вот именно. Прямо в точку. Только вот это:

относится не к процедурке. "Костылят" в основном на ООП. Ибо эта парадигма просто обязывает делать связи там, где они совершенно лишни. То, что призван делать язык PHP, никак не должно быть целым приложением. Это набор разных прграмм. И при нормальной структуризации в отдельной программке (модуле или еще как назвать) разобраться в сто раз проще, чем блудить в этих связях.

Вспомнить хотя бы те самые преславутые "паттерны проектирования". Вот самые костыли и есть. Придуманы для того, чтобы хоть как то этот бардак в порядок привести.

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

А с пропагандой ООП язык теряет свои позиции в своей нише, никак не завоевывая других.

Хорошо наверное, что есть такая возможность, использовать объектные архитектуры. Но это не прогресс для языка. Это просто дополнительная возможность, не более того.

Так чем конкретно не нравится в PHP? Чем ООП в java круче ООП в php?

Да никогда я не выдумываю длинных имен. Никогда. И никогда у меня ничего не пересекается.

Читай выше:

А вы стараетесь писать все в кучу. Конечно весь лоб в шишках от граблей.
Просто тебе не показали, как можно нормально спроектировать приложение, чтобы этих проблем не возникало никогда.

И вот это

полная ерунда. Так рассуждать, то нужно вообще никогда не использовать одинаковых имен. Даже в разных проектах. Мало ли...

Разделить пространство можно не только классами, а и нормальной структурой. И ничего страшного не случится, если разные части программы используют одноименные функции. Точно так же, как разные классы одноименные методы.

Об этом я тоже только что написал. Если квалификация программиста обуславливается сложностью его кода, а не рациональностью, то грош ему цена.

А если прогрессом считать искусственное усложнение там, где усложнять ничего не нужно, то это тупик. Это как делать автоматическую выдавливалку для зубной пасты.

Только ведь может потом найдется мальчик и скажет - "а король то голый!"

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

Если процедурный подход должен умереть, то С уже давно червяки должны есть

Ну вот.. а говоришь что согласен с twin'ом

У си своя ниша, поэтому и не помирает. Что конечно не значит, что весь мир держится на ООП.

Я уже 100 раз написал, что тем, что он тут бесполезен.
Напишу теперь в одном посте и собиру всё в кучу

Теперь понятно о чем я?
И прошу заметить, что я не против всего ООП, а только ООП в PHP.


P.S.:> А еще больше вырубает, когда сядет какой нибудь чел, напишет в классе всю программу, потом создаст файл index.php и съинклудит файл index2.php в котором класс находится. Такое вообще очень часто заметить можно.

Коротко по пунктам:
- в С объектов нет

Смысл создавать процедуры, которые ты "... в будующем ты не будешь их использовать в других своих разработках..."

У людей которые не думают сами - да.

То же самое верно и для функций.

С не изучал, только Java.

Дык и для чего изобрели велосипед, если разницы нет ? Я уже битый час про это толкую.
К тому же в использовании процедуры проще в раз 10.

Ну кхе, а по мойму их заставляют так думать - когда на работу не берут. Кхе.

Согласен, но не криворукии, которые книжку с классов читать начинают.
По этому более адекватно всё выглядит.

Вот скажи, чем в наше время отличается php от python? Не надо только говорить что php === personal home page.

Есть автолоад, который не подгружает то что не нужно в конкретном приложении. И кстати этого же автолоада нет в процедурном, отсюда и возникают дурацкие 1001 инклюд, о которых ты говорил выше.

Говнокодить можно даже на брэинфаке, это не аргумент.

Ты видел амурских тигров в живую? Нет? А они есть... Так же и смысл в других технологиях. Даже если он тебе не понятен.

Как минимум скоростью обработки машиной и лучшим взаимодействием.
+ Программировать на ООП в python горздо приятней было бы в виду хорошей читабельности своего кода.

Никто не говорит, что я его не знаю. Меня просто поражает то, что впринципе оно безполезно. Я буду программу на ООП кодить на Java, родом языке для ООП, а не буду писать приложение на php чисто для понту.
К тому же в своей производительности приложение будет отличаться.

ой ли))) Ведь лукавят те, кто говорит, что проектирование приложения идет сверху вниз. Сначала мол делаем абстрактный фундамент, а потом детлизируем наследниками.

Все равно перво-наперво в голове выстраивается все приложение. Ну за исключением частностей. Как в математике. Сначала математик видит теорему и её результат, потом только доказывает.

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

Так вот, проектировать процедурку нисколько не сложнее. Просто другие навыки и другой подход. Рациональный.

Кто не умеет рационально мыслить, тот спасается ООПэшными костылями.

Топик можно прикрывать, ибо доказывать все-равно нечего?

Для веб приложения 50-100 микросекунд роли не играют, тем более что память и тот и другой любят практически одинаково. Разница лишь в том, что в python есть нормальный cgi интерфейс, однако это же влечет за собой трудности написания приложений под него. Так что и не плюс и не минус

UnWind, провокатор

Ну не дадут соврать - я вообще несколько дней ни в одну тему носа не сунул. Не до того было. Сейчас вот отдыхаю)))

Можно посмотреть на тему?

http://phpforum.ru/index.php?showtopic=441...=0#entry1093552

Нука вот это место поподробнее. Ничего я не понял. Особенно не понял, причем тут вообще ООП-неООП.

На базе каких наработок? C каким "расширенным функционалом"?
В теме совсем не тот вопрос.

В теме не тот, верно. Но в этой теме суть вопроса в том как именно ООП подход может помочь в этом вопросе. Дабы не махать руками, я жду от вас, предложения по этому поводу.

А теперь подробно.

А я не хочу создавать страницу вызовом одной функции. Меня интересует база-решение для управления деревом отдельно, и база решений управления страницами отдельно. Ну это же нормально что мне в чем-то другом понадобится использовать теорию вложенных множеств? Конечно понадобится ... А потому, я взял и сорудил класс. Я изял выгоду из ООП, а именно инкапсуляцию. Я спрятал внутреннюю кухню, в которой достаточно много функций которые абсолютно не нужны системе, и очень нужны внутри класса который управляет деревом. Потом я создал потомка, который наследует методы и поля класса управляющего деревом, ну и дополнил его методами, которые позволяют одним вызовом, создать страницу, просто указав ,родителя. И решив задачу один раз, меня этот вопрос больше не волнует. И если гдето в классе была ошибка, я исправлю это раз и на всегда. И это решит проблему глобально, и не придется нигде в коде хоть что-то менять. Это и есть + в ООП.


Я слушаю ваше предложение

правильным решением предлагается иметь базовый класс с "наработками" и наследника с расширением функционала? И предпологается, что я предложил бы решать эту задачу функциями?

Так нет. Я бы предложил сделать это одним классом. И вообще не делить. Ибо задача достаточно специфична, функционал однотипен. Не вижу никакого смысла делить его на разные классы, тем более файлы.

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

Только причем тут ООП?

UPD Ну я не ошибся. Так и есть. Магическое слово "инкапсуляция" опять идет вразрез со здравым смыслом.

Какой в этом сокраментальный смысл? Разбросать функционал по задворкам, чтобы было потом удовольствием собирать это обратно, если потребуется использовать эту штуку в другом приложении? Или опять сочинять потомков?

В чем радость то? В том, что свято соблюдается принцип "черного ящика"?
Лично я плевать на него хотел. И мои классы (самодостаточные) совершенствуются с каждым разом, позволяя при следующем использовании интегрировать его несколькими вызовами нужных методов, не лепя тришкиных кафтанов из интерфейсов и не траятя время на сочинительство наследников.

Но это касается именно такого функционала, который может (и должен) быть реализован либой. Все остальное собирать по схеме родитель-потомки => пустая трата времени. Ибо затраты на проектирование не окупаются. Каждый раз проектировать приходится снуля.

Вот тут то я вас и поймал. Нет, задача далеко не специфичная. Я бы даже сказал, абстракция и потребность в абстрагировании настолько очевидна, что просто напросто ярче примера трудно найти. Потому что любое дерово Nested Sets требует наличия полей в базе данных таких как левый, правый ключи, уровень. Сама же страница ,которая может быть потомком категории фиг его знает какого уровня, это уже специфика, потому что у страницы есть свои поля. И класс, которые управляет деревом, спокойно можна применить в любой другой задаче. Пример с старницами это далеко не удел. И попытки повторять код в разных классах одной системы, обозвут г*внокодом. Можете быть в этом уверенны. Плевать на мнение других можно, часто даже нужно. Но вы не сможете себе этого позволить в условиях рынка, когда вашу систему нужно продать. И ваше мнение, личное, и может даже правильное. НЕ ОЦЕНЯТ.

И кстати, вы всетаки используете ООП. И это я понимаю. Ценю то что спор идет в том что не стоит его подключать надо и не надо. Тут я с вами полностью согласен.

Ну я бы не торопился с выводами.

Я это знаю. Только причем тут вообще таблицы? Или класс жестко привязан к конкретным таблицам? Тогда я вообще отказываюсь понимать.

Вот именно. Я бы и сделал класс для управления деревом. А все остальное к задаче отношения не имеет.

Правильно сделают. Ибо насколько я понял тут ошибка в самой архитектуре. Которая возможна как раз при таком расслабляющем свойстве, как наследование.

И еще, можно тут уточнить - что является "системой"? И почему я должен

?

Конечно можно просто сделать один абстрактный класс, а потом конкретизировать его в потомках, дописывая тонны кода. Только это ли не г*внокод? Переписывать из приложения в приложение кучу наследников?

Основной функционал для работы с деревом должен быть универсальным. Тогда стократ проще использовать его в разных скриптах. А наследование тут дело совершенно десятое.

Все, что выходит за рамки работы с деревом (создание страниц и т.д.) - это другая задача совсем. И решается совершенно различными методами. Я вот не вижу смысла делать такой клубок. Пусть он по объему будет меньше, но по прозрачности и повторному использованию останется далеко позади модульной схемы.

Это смотря какая система)))
Если я, наплевав на модные течения, придумаю что то более рациональное и прозрачное, а то и универсальное, еще как)) Есть опыт такой.

Только в рамках чужого кода. Или это вывод из того, что я использую классы? Так это не ООП вовсе.

Вот тут я не соглашусь. Продать можно всё что угодно, и говнокод в том числе (что чаще всего и бывает). Не оценят те, кто будет работать с исходником, а это уже другие люди, которые к покупке отношения не имеют. Опенсурс - единственное место где проект получит полноценную оценку сообществом программистов.

twin использует классы как обёртку для функций, которые решают одну общую задачу. А это не есть ООП. И он противник именно ООП подхода - длинючих цепей наследования, мутного паттерна "фабрика", итд.
Из моего опыта не было ещё задачи, которую нельзя было бы красиво решить без использования ООП.

Arni
Про nested sets - можешь организовать конкурс с этой задачей. Только попозже, как страсти с новым конкурсом утихнут.

facebook, vkontakte, travian, и если не ошибаюсь, то и habrahabr тоже. Проекты надо смотреть как сайты, которые приносят прибыль, и большую, а они на ПХП.

Класс относится к процедурке
<pre class="sh_sourceCode" rel="code">Зачем лепить в теле программы 1001 инклуд, и 1001 класс</pre> А на деле оказывается, что из 10 инклюдов, 9 - это разделение MVC, сама же индивидуальная страница подключает 1, или максимум 2 класса, что 1-2 инклюда для скрипта мизерны, но тот же класс позволяет облегчить работу.

Человек, которому 60 лет, он знает, что завтра от умрет, и толку от операционной системы на ПХП будет 0. Мне 23 года, за 20 лет производительность PC выросла в сколько раз? Посчитай, теперь прикинь уровень прогрессии развития процессоров, ведь в основном вся работа сервера зависит от него, ещё добавь память сюда. Итак, когда мне будет 43 года, те запросы, которые обрабатываются сейчас 1 минуту, будут обрабатываться за 0,001 секунду, кроме этого идёт разработка ПХП6, где будет развит ПХП ещё больше. Что мне мешает создать ОС в мои 43-45 лет? А будет мешать лишь ОТСУТСТВИЕ знаний, которые по "глупости" я не смог получить именно сейчас. Если ты не гуру в ООП, то все последующие сайты необходимо писать именно на ООП, чтобы научиться.

Бесплатный сыр бывает только в мышеловке. Ты можешь создать свой продукт и продавать лицензию за 1000$, и огромную структуру целостную нельзя будет нарушить, а значит за собой ты всегда оставляешь авторские права на продукт, а процедурка не сможет тебя выделить как автора проекта. Так вот, всё, что ты видишь - это бесплатный сыр.

Скажу коротко, я не в ответе за кривизну рук и кода, написанного за пределами моей студии. Качество подтверждается не подходом, а его реализацией! Пример: село, где часть пользуются современной мега техникой, либо бабульки, которые выращивают свою собственную незатравленную картошку, так вот, я покупаю именно второй вариант, потому что картошка более качественная получается.

И получаются низкосортные копи-паст сайты: "интернет-магазин за 2000 рублей", "сайт-визитка за 300 рублей", "портал знакомств на джумле за 500 рублей". "10 сайтов за 5 000 рублей", и это только мизерная часть того, что просят на фрилансе. А теперь в противовес покажу качественные проекты: "Социальная сеть: 200 000 рублей", "Поисковая система по примеру Гугла и яндекса: 500 000 рублей", "Пакет сайтов знакомств: 250-300 000 рублей", вот и подумай, у кого из них "сайт запихнули в 1 класс под именем index2.php" ?

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

Ну и самое последнее: ООП и КЛАССЫ - это разные вещи.

Пишешь класс с кучей методов - на каждое действие (которые ты описал). И всего делов!

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

Я как раз и стараюсь писать так, чтобы такой востребованный функционал, как работа с деревом к примеру, был самодостаточным. А как его интегрировать - наследуя или прямыми вызовами - к контексту отношения не имеет. Лично я не вижу смысла плести такую паутину. Пусть это немного объемнее и на первый взгляд дольше (что совершенно не так), но зато прозрачнее и универсальнее.

ApuktaChehov
Слишком размыто, чтобы сказать что-то конкретное. Но я не вижу особых проблем. Вообще не вижу особой разницы, как реализовать.
И уж тем более не понимаю, что есть

Логика приложения будет такой, какой ты её сделаешь. Сама по себе она не бывает ни объектной, ни процедурной.

И теперь вот это.

Что-то не склеилось у меня по вашим утверждениям.

я не собирался делить.

Что значит

? Смею предположить базовый класс. По видимому абстрактный. А вот это:

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

Так вот. Я бы всё, что касается работы с деревом, поместил бы в отдельный класс. Все остальное, создание страниц и прочие телодвижения - отдельная задача.

От того и написал, что у тебя

Так как ты свой клубок, запутанный с таблицами, страницами и деревом в "одной системе" ни за что не сможешь использовать в другом приложении, не внося глобальных корректив. Ну если это конечно не полная копия.

Тебе полюбому придется переписывать потомков.

Ты забыл уточнить - твоего проекта. Потому что в отрые от него вся эт "красота" - полный пшик.

Да и просто запустить его не каждый сможет. Потому что ты там понаворотил своих прибамбасов вагон и телегу.
О чем я и говорил. Удобно только тебе. Все остальное - побоку.
Тонна кода, фишки-шмишки, псевдо-крутость, а на деле - муть и бесполезность.

Так же в свое время Вася писал гостевую на ООП. Тот еще шедевр.
Как работа для резюме - отлично. И та работа и твоя. Запудрить моск работодателю. А на практике - фикция.

Нужно наверное памятку сделать и туда пруфы давать... Повторяется все одно и то же.
Причем тут сложность проекта? И количество народа?
Нормально организовать взаимодействие программистов можно не только поделив зоны влияния области видимости. Это уже организационные вопросы.

А вот последующая поддержка проекта (особенно в продакшене, где с ним будут иметь дело сторонние программисты), не менее важна для веб.

Почему именно для веб. Поясню. Что такое сайт и как его используют.
Вот сделал linker интернет-магазин к примеру. Он крут, там куча наваротов, работает просто безупречно. Заказчик доволен.

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

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

А linker двно уже другими делами занимается, связь с ним потерена и вообще ему недосуг.
Заказчик кидает клич - "ищу программиста, умеющего разбираться в чужом коде". Знакомо?
Находится такой. Открывет и...
поправив на голове вствшие дыбом волосы заявляет. Стоимость моих услуг - 20$ в час. На изучение доков мне нужно 3 дня. Потом посмотрим, как и что я смогу там поправить.

Заказчик считает, считает... И заказывает новый сайт.

История из жизни. У меня такое было неоднократно.

Все тоже самое касается фреймворков. Если повезет найти сразу специалиста, тот уже стоит дорого. А если нет - читай сначала. Часто бывает так - я хочу чтобы сделал именно ты. А я не знаю фреймворка. Приходится рыться в доках, что стоит заказчику денег.

Теперь другая схема. Любой программист открывет сделанный процедурно сайт и видит там привычные функции. Ему остается только понять логику, что в процедурке гораздо проще. Так вот такую работу делать - удовольствие. Даже ляпы испралять попутно - радость. Потому что все предельно ясно и все на месте. Не нужно бояться, что гдето на другом конце сайта чего-то рухнет из-за связей и "красоты".

Я плотно имел дело с вики-движком. Адаптировал под какие-то конкретные нужды. Никогда, под страхом смерти я больше за такую работу не возьмусь.

Но если бы эти 10 сайтов сделали несколько программеров на разных фрейворках... То придется изучать все эти фреймворки Либо - искать кучу программеров, каждый из которых хорошо знает определенный фреймворк.

Ты работаешь на своем фреймворке, обслуживаешь одну систему. И привык к ней. Тебе кажется все просто и красиво.

Мне же часто приходится иметь дело со сторонними разработками.

Так вот. Запутать процедурный код - нужно ооочень постараться. А в ООП изначально без 100 грамм делать нечего. Хоть фреймворк это, хоть мреймворк.
Потому что сама парадигма такова, что никогда прозрачной не будет.
Так что я скажу с точностью до наоборот. Гораздо хуже копаться в ООП гумне, потому что мало того, что и так гумно, так еще и твой Вася понаговнокодил.
Чистый говнокод разобрать можно просто в резиновых перчатках. А вот ООПговнокод (а 90% сайтов на ООП именно так и написаны) - тут нужно пару ассенизационных машин вызывать.

Ты рассуждаешь чисто теоретически, вроде как на первый взгляд даже логично. Но к действительности это отношения не имеет буде выдернуто из розовых рамок теории в суровые будни. Как и твой скрипт не имеет практического применения вне контекста твоей системы.

Повторяться не буду - надоело.

(с большой буквы). Болше чем уверен, что и я, и linker начали бы плеваться, глядя на этот Фреймворк.

Ровно как я считаю полной бредятиной ZEND фреймворк. А люди крестятся в страхе - богохульник! Его же разрабы PHP писали!!! Свят, свят.
Ну что поделать, если мне он не нравится.

Так что kirik прав - любой код говно. Наговнокодить могут все, человеку не чуждо ничего человеческого. Английская королева тоже какает и ковыряет в носу.

Так вот, дело тут в степени этой, назовем более мягко, "какости" кода. А она определяется:

1. Кривизной архитектуры
2. Отсутствием прозрачности
3. Использованием суррогатного синтаксиса
4. Дремучестью стиля написания
5. Бестолковостью алгоритмов.

И если пройтись по пунктам и сравнить:

1. Посмотрите конкурсную работу №4, вот пример того, как проектируется ООПговнокод. Сделать основной класс наследником конфиги - обречь его на единичное использование. Тоесть для другой таблицы уже никак. Говнокод? О, еее. Так вот в процедурке такое впринципе невозможно. Сейчас мне возразят - возможно другое. Но. То, что возможно в процедурке, легко говнокодится и на ООП. А вот обратной совместимости нет. Так что тут плюс один объектам.

2. Прозрачность. Будем спорить? Или так ясно? Если я смотрю функционал наследника, а родительский класс (а то и несколько по инстанции) находятся черти где, смогу я понять картину происходящего? Особенно если высока степень абстракции. Что вот это такое?

$form->setMethod('post')
    ->setAction('/mypage')
    ->addDecorator('formElements')
    ->addDecorator('htmlTag', array('tag' => 'table'))
    ->addDecorator('form');
$form->addElement('text', 'username', array('disableLoadDefaultDecorators' => true, 'required' => true, 'label' => 'Логин'));

$form->username->addDecorator('viewHelper')
    ->addDecorator('errors')
    ->addDecorator(array('tdTag' => 'htmlTag'), array('tag' => 'td'))
    ->addDecorator('label', array('tag' => 'td'))
    ->addDecorator(array('trTag' => 'htmlTag'), array('tag' => 'tr'));

Пример я уже приводил, лень искать другие. Ну? Что за декоратор, что он такое делает, с чем его едят? Ищи-свищи.

Да, процедурка потому и объемнее, что зачастую приходится повторять код в модулях. Но прозрачнее, стопудов. Так же используются функции и те же классы, которые в других файлах, но логика функционала вся на виду.

Так что по какости в области прозрачности ООП дает сто вперед процедурке.

3. Смотри пример выше. Это всего навсего генерация формы в табличном виде. Другими словами - верстка. А ну, покажите это верстальщику. Как думаете, сколько раз он упоменет в своем комментарии мужские гениталии?
А потому что это - ООП фреймворк. Это использование альтернативного синтаксиса.
Вот если включить счетчик, то тут количество матов будет существенно меньше (это тоже самое):

    echo "<form action=\"/mypage\"  method=\"post\">\r\n";
    echo $errors;
    echo "<table width=\"100%\" border=\"0\" cellspacing=\"0\" cellpadding=\"0\">\r\n"
       . "<tr>\r\n"
       . "<td>\r\n"
       . "Логин <input name=\"username\" type=\"text\" />\r\n"
       . "</td>\r\n"
       . "</tr>\r\n"
       . "</table></form>";  

Говнокод? О, да! Как же, а где разделение? Кто так по детски пишет!
Ну ладно, согласимся. Сделаем разделение. Обычным нативным синтаксисом (не забывая поглядывать на счетчик матов, подключенный к верстальщику)

<form action="/mypage"  method="post">
<?php echo $errors; ?>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
  <tr>
    <td>Логин <input name="username" type="text" /></td>
  </tr>
</table>

А так же можем посчитать количество символов (к вопросу о прибавке в скорости от фреймворка).

Ну будут еще попытки убедить окружающих в том, что суррогатный синтаксис фреймворка выгоднее? Лично я ставлю в этой позиции ООП жирный минус. —

4. Тут один-один. Все зависит только от аккуратности писавшего, от его уважения к последователям.

5. Ну и тут паритет. Хотя я мог бы возразить таким примером:

class 
{
   public function display($text)
   {
       if(!print ($text))
	       throw new Exception('Фууууу!');
   }
}

но чуствую - закидают шапками ссылками на говнокод.ру
Один-один так что.

Подведем итог.

С убедительным отрывом в 3 очка в чемпионате по говнокоду пооообеждаааает ОоооооооООООооооПээээээээээ!


Есть еще попкорн у кого? :)

$form->setMethod('post')
    ->setAction('/mypage')

это приведение html к объекту (как в JS/FLEX).

Вот :)

Присылайте результаты мну, а я уж выложу

Уверен, что эти 50 можно превратить в 20, или даже в одну.. Только кроме тебя там никто не разберется. В моём велосипеде только базовая часть занимает 5кб (обслуживание конфига, роутинг и bootstrap с несколькими основными действиями). Что можно уместить в 3.8, при том чтобы код был не только write only - я не могу представить
Если разработка не секретная, то может поделишься с сообществом?

Согласен но такая дуэль это же так интересно!

Я вот планирую свою ЦМС уже скоро повторно вынести на рассмотрение. Правду сказать, нахренячил я там чуток с ООП, буду переписывать позже. Но это уже привычка, переписывать, переписывать, переписывать.

А веду я к тому что вместе с тем как растет моя ЦМС, меняется мое отношение к процедуркам, к ООП, к программированию и к миру в целом. В общем не поменяет свое мнение только тот кто ничего не делает.

Да мне кажется что я начинаю понимать к чему клонит twin.

Вот как менялось у меня мнение.

1. Сначало я не понимал что такое ООП , и не понимал нафига оно вобще надо в ПХП, ведь это же не приложение которое после запуска становится процессом. И в этом случае ООП это сила. Потому был противником этого подхода.
2. Потом с ростом сложности системы, когда я умудрился пару раз нарваться на повторное объявление переменных (я про то что мне казалось что такой еще небыло), я понял что может ООП, это и плохо, но вот инкапсуляция это всетаки не плохо.
3. Я увлекся, и нагородил кучу связей и вызовов внутри класса. Чем добился только того что сам уже не понимаю как оно вобще нафиг работает.
4. Что-то уже переписал, что-то еще писать. Но уже более сдержанно отношусь к ООП.

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

Что не мало важно в ООП для пхп, это деструкторы. Память надо освобождать. Это полезно, поскольку есть ощущение что fpm скоро станет намного популярнее. А рябить unset, это не выход. Одним вызовом деструктора, интерпретатор грохнет целую кучу добра. А Бог уже розсортирует .

Ну так вот про то к чему как мне показалось клонит twin. Сами видите, он использует классы, и он не то чтобы противник того чтобы их делать, он за. Но вот ООП, в том виде как это в С++, в пхп не будет никогда. Потому что этом припятствует святая святых серверного приложения.

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

В одном из многочисленных холиваров на эту тему я то же самое написал Чуть другими словами, но суть та же самая. Правда, мне для этого не надо было много работать с классами в ПХП, потому что я сколько-то поработал с классами в Си++. А придя в ПХП понял, что тут классы нужны, но не так, как в Си++. Примерно так, как ты описал.

А что изменилось за последние год - два?