Comments 53
быть может я недалек, но что-то мне подсказывает, что пользование такой "фишкой" только усложнит понимание и сопровождение кода
Я всё ещё опасаюсь в очередной раз с вами спорить, но всё-таки скажу что иногда и это может пригодиться.
P.S. Ох, чувствую, доказать трудно будет :)
P.S. Ох, чувствую, доказать трудно будет :)
Сегодня-завтра опубликую вторую часть - там будет пример использования рассмотрен.
Согласен, похоже на какой-то кошмарик. Почему нельзя просто завести виртуальную функцию, возвращать в ней что надо и переопределять ее в тех классах где это нужно?
Нет не усложнит, наоборот упростит. Будет тоже самое, что и для динамических методов.
Многие программные модели станет проще реализовывать :)
Многие программные модели станет проще реализовывать :)
ну у меня слова "перегрузить", "переопределить", "перекрыть" ассоциируются с методами ...
с константами такие ассоциации никак в голове не укладывается. На то они и константы.
А своих работах я вижу, где за счет этой фишки я могу убрать 5-10 строк кода (заменить геттеры), но делать этого не стану, ибо константа должна быть константой
с константами такие ассоциации никак в голове не укладывается. На то они и константы.
А своих работах я вижу, где за счет этой фишки я могу убрать 5-10 строк кода (заменить геттеры), но делать этого не стану, ибо константа должна быть константой
Почему обязательно константы? Вся соль в том, что непереопределенный родительский метод будет знать, что вызывают его из наследника, а не так как сейчас. Сейчас он думает, что его напрямую вызвали.
честно признаться не понял что вы сказали, скорее всего из-за своей недалекости, но вот последнее предложение у меня вызвало массу эмоций:
>> непереопределенный родительский метод будет знать, что вызывают его из наследника, а не так как сейчас. Сейчас он думает, что его напрямую вызвали.
Один из канонов ООП - инкапсуляция. Ни один метод объекта никогда даже намеком не должен знать откуда его вызвали.
>> непереопределенный родительский метод будет знать, что вызывают его из наследника, а не так как сейчас. Сейчас он думает, что его напрямую вызвали.
Один из канонов ООП - инкапсуляция. Ни один метод объекта никогда даже намеком не должен знать откуда его вызвали.
Рассмотрим пример:
Во втором классе Bar переопределена только статическая переменная. Указание $this в методе dyn() позволяет узнать имя класс, без него всегда вернет Foo. В статическом методе ничего подобного реализовать нелья, поэтому необходимо переопределять метод, как в классе Habr. Это вызывает неоторые неудобства. Со статической переменной думаю тоже все понятно.
Во втором классе Bar переопределена только статическая переменная. Указание $this в методе dyn() позволяет узнать имя класс, без него всегда вернет Foo. В статическом методе ничего подобного реализовать нелья, поэтому необходимо переопределять метод, как в классе Habr. Это вызывает неоторые неудобства. Со статической переменной думаю тоже все понятно.
<?
class Foo {
static $var = 'dima';
function dyn()
{
echo 'Dynamic: ', get_class($this), "\n";
}
static function stat($class=null)
{
if (is_null($class))
{
$class = get_class();
}
echo 'Static: ', $class, "\n";
}
static function stat_var()
{
echo 'Variable: ', self::$var, "\n";
}
}
class Bar extends Foo {
static $var;
}
class Habr extends Foo {
static $var;
static function stat($class=null)
{
parent::stat(get_class());
}
}
$obj = new Bar;
$obj->dyn();
Bar::stat();
Bar::stat_var();
Habr::stat();
?>
Он не знает, откуда он вызван. Он знает какому классу принадлежит.
>>Один из канонов ООП - инкапсуляция. Ни один метод объекта никогда даже намеком не должен знать >>откуда его вызвали.
к инкапсуляции это не имеет ни малейшего отношения
к инкапсуляции это не имеет ни малейшего отношения
Для товарищей, которые курят нормальные мануалы, программили на ЦПП и шарят в ООД — вряд ли.
Это вовсе не «фишка» — это наконец нормальная реализация, а то обычные методы в PHP всегда виртуальные а статические получается — никогда не виртуальные?
Теперь все работает как ожидалось, а это довольно важно в программировании.
Теперь все работает как ожидалось, а это довольно важно в программировании.
UFO just landed and posted this here
Тут разработчик наш говорит что LSB в CSV уже месяца три.
"зачем-зачем". забыли, например, про паттерн синглтон ?
Возможность конечно клевая, НО она доступна начиная с PHP 5.3.0
А текущая стабильная версия 5.2.5. Когда мы этим всем поспользуемся не очень понятно...
А текущая стабильная версия 5.2.5. Когда мы этим всем поспользуемся не очень понятно...
не хватало очень раньше позднего связывания.
раньше приходилось делать через жопу protected static.
кстати почему вы ничего не написали про __callStatic ?
раньше приходилось делать через жопу protected static.
кстати почему вы ничего не написали про __callStatic ?
Нужная вещь которой давно не хватало в PHP. Без нее нормальный ORM не сделать. Неполучится красиво написать $user = Users::find($user_id), раньше этого добивались через *опу.
Получается, что смысл такой "фичи" в том, чтобы иногда можно было обойтись без перегрузки методов.
Если разбирать чужой код, то перегрузка получается более прозрачной, чем LSB.
Если разбирать чужой код, то перегрузка получается более прозрачной, чем LSB.
Что по вашему лучше? Это?
Или это?
Неужели не прозрачно?
<?
class DAO {
static function getObjects($class_name=null)
{
$sql = 'SELECT FROM '.$class_name;
}
}
class News extends DAO {
static function getObjects($class_name=null)
{
parent::getObjects(get_class());
}
}
class Faq extends DAO {
static function getObjects($class_name=null)
{
parent::getObjects(get_class());
}
}
$news = News::getObjects();
$faq = Faq::getObjects();
?>Или это?
<?
class DAO {
static function getObjects()
{
$sql = 'SELECT FROM '.$class_name;
}
}
class News extends DAO {}
class Faq extends DAO {}
$news = News::getObjects();
$faq = Faq::getObjects();
?>Неужели не прозрачно?
Честно говоря, кажется костылем.
С выходом 5.3 все начнут писать абстрактных синглтонов :)
Три года этот баг в багтракере висит! Ужас.
О ну наконец-то! Как я в свое время с этим натрахался.
Приходилось жутко хачить через debug_backtrace...
Приходилось жутко хачить через debug_backtrace...
Наконец-то, давно пора, а то статические свойства и методы в PHP вообще слабо развиты. Они бы еще с функциями что-то порешали, local как в перле добавили или позволили бы объявлять, замыкания, хотя на это надеяться не стоит наверное ;)
Ура!! свершилось! как часто приходилось извращаться чтоб решать эти проблеммы! теперь реально многие, очень многие вещи можно будет делать по-человечески! Спасиб огромное автору - отличная новость!
Имхо. думаю что ввод такой константы во времена первого использования будет вызывать лёгкое раздражение при дебажинге, так как перестанешь доверять тому что константа на самом деле и не константа, что повлечёт за собой просмотр родителя каждый раз при наращивании функцивнала через длительный промежуток времени простоя кода.
Вообще-то, это не ООП-style.
Статические члены тем и отличаются от динамических, что принадлежат типу (классу), а не объекту. Поэтому наследование и перекрытие никак не должно на них влиять, это сродни сквозной функциональности.
Наличие же позднего связывания развяжет руки ради мнимой выгоды. "Наследование статических членов"... Не должно такого быть. Как бы красиво это не выглядело.
Статические члены тем и отличаются от динамических, что принадлежат типу (классу), а не объекту. Поэтому наследование и перекрытие никак не должно на них влиять, это сродни сквозной функциональности.
Наличие же позднего связывания развяжет руки ради мнимой выгоды. "Наследование статических членов"... Не должно такого быть. Как бы красиво это не выглядело.
Sign up to leave a comment.
Позднее статическое связывание в PHP (Часть I)