Меню
Что нового?

Хех... Интересные грабли....PHP5.3+

cDLEON

cDLEON

Онанист РНРСlub
Хех... Интересные грабли....PHP5.3+

PHP: 
class test1 {
 public static function testing_method() {
  var_dump(get_called_class());
 }
}
class test2 {
 public static function testing_method() {
  parent::testing_method();
 }
}
Возвращает test2.... :)
PHP: 
abstract class test1 {
 abstract public static function blabla();
}
class test2 extends test1 {
 public static function blabla() {
 }
}
Ругается:
Strict standards: Static function test1::blabla() should not be abstract in ........ on line 19.
 
cDLEON

cDLEON

Онанист РНРСlub
fixxxer
ну вообще вторым способом я пытался обойти первый, который не работает =)))
В данном случае пишу я ОРМ. И что бы как то заставить программиста сразу описывать структуру таблицы в классе, вот так вот извратился)
А вообще с late static bindings помоему такой код имеет право на жизнь ) Хотя выглядит не совсем красиво. Но, помоему, ни чем не отличается от this->blabla(); в случае с обычным публичным абстрактным методом.

-~{}~ 30.08.10 19:55:

Вообще интересен сам факт того, что во втором куске кода пыхпых ругается ошибкой.
Ведь, если я сделаю так:
PHP: 
interface test_interface{
    public static function blabla();
}
abstract class test1 implements test_interface {
}
class test2 extends test1 {
 public static function blabla();
}
Ни кто ругаться не будет.
 
fixxxer

fixxxer

К.О.
Партнер клуба
Ты это прекращай, а то дойдешь до реализации наследования на LSB :)

Не надо так делать :)
 
cDLEON

cDLEON

Онанист РНРСlub
fixxxer
Бггг. Как ты догадался? :D
Я действительно реализую наследование полей таблицы ( в данном случае свойств класса) :D
Т.е, грубо говоря, хотел сделать нечто такое
PHP: 
class table {
 protected static $fields=Array(
  'id'=>Array(/*some properties*/);
 );
}
class table2 extends table {
 protected static $fields=Array(
  'name'=>Array(/*some properties*/)
 );
 // А далее для подхватывания свойств из класса-родителя - переопределяем 1  метод. Примерно так:
 public static function get_fields() {
  return parent::get_fields() + self::$fields;
 }
}
Здесь есть какие-либо подводные камни?

-~{}~ 30.08.10 21:05:

http://bugs.php.net/bug.php?id=52741
----
В ответе модера тоже есть доля правды...
Эх... Сделали из статических свойств костыли =\

-~{}~ 30.08.10 21:18:

А вообще... В стиле СИ++ очень даже такой вариант прокатывает:
PHP: 
class table extends orm\table {
    protected static $fields = Array(
	'id' =>   Array('type' => self::TYPE_INT,'primary'=>TRUE),
	'name' => Array('type' => self::TYPE_CHAR,'length'=>255)
    );
}

class table_extended extends table {
    protected static $fields = Array(
	'name2' => Array('type' => self::TYPE_CHAR,'length'=>50)
    );
    public static function get_fields () {
	return table::get_fields()+self::$fields;
    }
}

class table2_extended extends table_extended {
    protected static $fields = Array (
	'name3' => Array('type'=> self::TYPE_CHAR,'length'=>75)
    );
    public static function get_fields () {
	return table_extended::get_fields()+self::$fields;
    }
}
 
Духовность™

Духовность™

Продвинутый новичок
офф. зачем а table2 наследовать поля table1 ? Какой в этом сакрально-ООПшный смысл? Запутаться? И вообще, ситуация с наследованием свойств таблицы - это редко.
 
cDLEON

cDLEON

Онанист РНРСlub
triumvirat
Ну вот, к примеру, имеем мы модель comments, которая использует таблицу comments_table, в другом модуле нам нужен функционал comments + несколько полей, допустим с каким-нибудь рейтингом или ещё что-нить там...
Наследуемся от comments - получаем новую таблицу которая берёт все свойства от наследуемой и добавляет пару своих свойств. В модели имеем уже реализованные базовые методы от comments и пару новых - например запрос комментов с высоким рейтингом. Неужели такое решение запутанное и не красивое? :)
PS. В шапке форума "Переходим на PHP5.3.3" а тег [ php ] режет нэймспэйсы =))
 
Духовность™

Духовность™

Продвинутый новичок
не красивое, ибо "comments + несколько полей" - это какой-то абсолютно надуманный вариант реализации.

Давай дальше рассказывай что ты там делаешь. Код выкладывай.
 
cDLEON

cDLEON

Онанист РНРСlub
triumvirat
Конечно надуманное, я же его специально для ответа придумал.
Смысл этой кухни в том, что бы _расширить_ базовые возможности модели, что бы получить новую отдельную сущность, но без копи-паста кусков кода.
 
Adelf

Adelf

Administrator
Команда форума
не красивое, ибо "comments + несколько полей" - это какой-то абсолютно надуманный вариант реализации.
Нажмите для раскрытия...
Статьи + несколько полей, таких как фотка к статье например - надуманный вариант?
 
Духовность™

Духовность™

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

Я не пытаюсь сказать, что решение cDLEONа плохое. Оно по-моему просто абстрактное через чур. 95% систем не будет пользоваться наследованием свойств. Ну да ладно, закроем тему.

-~{}~ 30.08.10 21:50:

'id' => Array('type' => self::TYPE_INT,'primary'=>TRUE),
'name' => Array('type' => self::TYPE_CHAR,'length'=>255)
Нажмите для раскрытия...
как и в каком виде это будет использоваться?

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

-~{}~ 30.08.10 21:54:

а ты фактически описываешь в модели SQL-структуру таблицы! Зачем?
 
cDLEON

cDLEON

Онанист РНРСlub
Сомневаюсь, что в системе будет модель статьи и модель статьи с фоткой. Зачем такое разграничение нужно? Зачем дляэтого городить две разные модели?

Я не пытаюсь сказать, что решение cDLEONа плохое. Оно по-моему просто абстрактное через чур. 95% систем не будет пользоваться наследованием свойств. Ну да ладно, закроем тему.
Нажмите для раскрытия...
В единой апликухе - да, скорее всего, не будет модели и отнаследованой от неё модели (хотя такое развитие событий я всё равно не исключаю). Только что мешает написав единожды модель "статья" использовать её как базу для последующей апликухи, в которой понадобится модель "статья с фотками" ?

-~{}~ 30.08.10 22:14:

и все? Какую ещё полезную роль играют эти описания, кроме как возможности создавать таблицы?
Нажмите для раскрытия...
Делать автоматический update таблицы в БД, например.
Ну до кучи вспомним про наследование - меняем, что либо в модели "статьи" (какие то функциональные улучшения) - меняется и в наследуемых таблицах.
Кроме этого - эти данные можно использовать для валидации данных полученных от пользователя.
 
Духовность™

Духовность™

Продвинутый новичок
Да я понял, что свойства модели = структура таблицы. Вопрос - зачем структуру таблицы в том или ином виде хранить в классе модели?
 
cDLEON

cDLEON

Онанист РНРСlub
triumvirat
я же описал.
Делать автоматический update структуры таблицы в БД, например.
+2 последних пункта.
 
флоппик

флоппик

promotor fidei
Команда форума
Партнер клуба
Вопрос то кстати почти правильный -
зачем структуру таблицы в том или ином виде хранить в классе модели?
Нажмите для раскрытия...
зачем - понятно. Непонятно - зачем по этим данным вносить изменения в структуру?
ОРМ - это проекция структуры БД на обьект, а не наоборот.
 
Войдите или зарегистрируйтесь для ответа.
Сверху