asserte

Или копать в сторону zlib из phpMyAdmin - самый простой путь. И юзается во многих приложениях...

А еще можно использовать exec (если хостер позволяет ;))

Примеры? Пожалуй, TreeStructure - как пример. Добавление/удаление Items/Nodes (одинаковые методы - только вот разные таблицы, которые можно переопределить при наследовании). Сюда попадают все нециклические деревья: категории/статьи, категории/картинки, категории/видео и т.д... Вот вам и наследование... =)

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

Впрочем, холливар =)

Интересно конечно, но API для своего кода, я так понимаю - нельзя посмотреть, ибо CORE закрыт.

ЗЫ: а что такое

$_SESSION['password']=='d41d8cd98f00b204e9800998ecf8427e' ? '' : $_SESSION['password']

В CUser::authenticate() ? :-D

После этого ВТРОЙНЕ интересно, почему код закрыт. Чесслово... Странные штучки-дрючки )

Тормозит он дико из-за неверной архитектуры БД. Можете посмотреть на досуге - сам сталкивался. А еще не забываем о том, что он с графикой работает - это ресурсоемкие операции. (если мы про админко и операции с изображениями).

Насчет расширений... А вот тут уже вопрос не ООПрограммирования и не ООПроектирования. Тут архитектурное проектирование задействовано.

Я что-то очень сомневаюсь, что они на процедурном напишут =)

А по теме "доабстрагировались" - не означает, что на каждую сущность системы надо по 20 оберток писать. Я к адаптерной системе в 2 обертки пришел. Ничего - шустренько работают системы (профайлинг показывает, что основные 90% - это СУБД). Не стоит говорить о ООП как о сильно тормозящем системы подходе. Системы можно тормозить еще и циклами :)

Devider, Снова вы на конкретные реализации привязываетесь... Вам ли не все равно, как будут кешироваться конфиги: пофайлово, поштучно или вообще генериться в нативный php-код? )

Учитесь абстрагироваться от кода - это для меня важнейшее качество ООП-подхода. Почитайте банду четырех - вообще летать будете, когда начнете применять паттерны ;)

Напомнило "Я пони. Обоснуйте". Доказать можете, что ооп здесь не нужен? Чтобы вас уверовать в жизнь - приведу пример своей реализации системы конфигурации:

A_ConfgInterface - интерфейс

A_ConfigAPI - Адаптер для работы с конфигами

A_ConfigFabricanto - фабрика объектов конфига.

Приступим? =)

<?php

$Config = new A_ConfigAPI();



$Config->extract('configName', 'database', 'tablename'); // АPI запускает фабрику объектов с сигналом 'database', просматривая перед этим наличие кеша. Ложит в свой стек имя полученого конфига, регистрирует в диспетчере

$Config->extract('configName2', 'fs', 'app::configs::users'); // То же самое. Только фабрика инстанциирует другой объект работы с конфигом, который так же имплементирует A_ConfigInterface



$singleConfig = $Config->get('configName');

$allConfigs = $Config->getMerged('configName', 'configName2', 'confgName3',...);

$Config->cache($allConfigs);

Что получили?

1. Стандартный интерфейс работы с конфигурацией в системе. Не нужно помнить как работает система конфигурирования в ядре, а как - в приложении

2. Стандартный интерфейс для хранения и кеширования конфигураций

3. Стандартный интерфейс доступа к конфигам

4. Расширяемость за счет фабрики (XML/YAML/FTP/Oracle...)

5. Центральный валидатор конфигураций - A_ConfigAPI

Могу долго так продолжать... А в процедурном секса нас ждет, чтобы такое реализовать - мама не горюй (

Devider, я все-равно не понимаю, нахрена костыли...

Не проще сделать так:

<?php
// На этапе инициализации
$UserConfig = new ConfigObject();
Dispacher::registerObject($UserConfig, 'userConfig');

$UserConfig->setSource('database', 'configTable');
$UserConfig->read();


// На этапе использования, где-нибудь в классе Users
$this->_configs = Dispatcher::getObject('userConfig');
// Все, готово к использованию. Улыбаемся и машем машем и улыбаемся

Чем полезен такой подход:

При serialize(Dispatcher::getInstance()) можно и нужно проверять типы объектов, хранимых внутри. Ложить все конфиги в единый файл (почти нативное кеширование получается). При wakeup - просто заполнять объект данными из массива.

В случае с глобальным конфигом - нужно еще понимать, что у тебя в глобальной перменной можно кешировать, а что нет... Как понять? На уровне объектов - все просто:

<?php 

if( $object implements Serializable &&
   $object->cacheEnabled()) {
 serialize($this->_data['userConfig']); // __sleep, разумеется
}

Финита

-------------

Название топика, если что: "Зачем нужны классы в php". Тут никто не спорит о том, какой подход лучше.. Скорее - как можно применять ;)

А состыкуется это примерно следующим: я как-то дописывал систему, в котором были глобальные переменные $CONFIG, $Config, $_Config, $_config... Ей-богу не вру. Вот как в такой каше разобраться? При учете, что кода кило на стописят, как минимум...

Спорим, не обойдется без массива? =)

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

Один из вариантов развития - использование неймспейсов в качестве оболочки для функций (читай - "альтернативы" статическим классам). Вот когда нужно будет показывать уличную магию, чтобы понять как это работает :-D

Что значит "тру"? ООП - он или есть, или его нет. Если нужно гарантировать один экземпляр класса - чем не путь? Земеттье, я употребляю исконно "ООП-термины". А как насчет геттеров/сеттеров? Они не нарушают Ъ концепции? Ведь данные в итоге оказываются "вне объекта". Тоже не Ъ? Другое дело - использование мощи ООП или пародия "для удобства".

Если уж на то пошло - ткну в противоречие между наследованием и инкапсуляцией. Слышали о таком? =)

UPD: что-то на ум упало... А ведь 99% разрабов начинают использовать классы и объекты как "контейнеры" для функций. Чтобы с именованием не путаться... Надо опрос устроить - сколько человек так начало свой путь к ООП ;)