Переопределение статических членов класса в PHP5

[su1d]

буквально вчера нашёл ещё косяк в том, что нельзя сделать:

class A {
     const something = '1'.'2';
}

т.е. не позволяются expressions в инициализации констант и свойств классов. дебильно как-то =(
порыскал по internals: Andi кажется послал всех с этой фичой на хрен и сказал, что скорее всего так и будет.

 

[tony2001]

>дебильно как-то =(
ну так это и в PHP4 так было.
попробуй:

class Test {
	var $test = "123"."123";
}

вполне нормально и ожидаемо имхо.

 

[su1d]

вполне нормально и ожидаемо имхо.

а мне вот давеча потребовалось туда вставлять что-нибудь более динамическое =/

 

[tony2001]

su1d
делать это в конструкторе не пробовал? =)

 

[Profic]

tony2001
Дык константа-то ведь Её в конструкторе еже не определишь. С переменными вопросов нет

Кстати нашел тут вчера возможное решение для товарища:

class a {
  const test = "qqq"
  function test2 () {
    return self::test
  }
}

PS. Просьба ногами сильно не бить, если оказалось, что не так.

 

[tony2001]

Profic
в том-то и дело, что он не хочет делать спец. метод для этого.

P.S. судя по всему, патч из письма Greg'a уже не пустят в 5.0. Про 5.1 все еще жду ответа от Zeev или Andi..

 

[smokemaker]

Originally posted by Profic
tony2001
Дык константа-то ведь Её в конструкторе еже не определишь. С переменными вопросов нет

Кстати нашел тут вчера возможное решение для товарища:

class a {
  const test = "qqq"
  function test2 () {
    return self::test
  }
}

PS. Просьба ногами сильно не бить, если оказалось, что не так.

Дело в том, что хотелось метод доступа определить _однажды_ в родительском классе и больше не париться. А такую обертку придется писать в каждом дочернем классе. Впрочем, я об этом уже говорил.

 

[Profic]

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

 

[tony2001]

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

 

[smokemaker]

Согласен, без этого можно обойтись. Но дело в том, что проект этот делается исключительно для себя и соратников, так что есть возможность исследования и эксперимента. Тем более, расширенные возможности ООП в 5.0 являют собой большой соблазн. Так что, как я сказал в самом первом посте, решение вполне может оказаться неверным
Но, тем не менее.
Итак, хотелось вот что - сделать некое Web-приложение, причем так, чтобы впоследствии по необходимости к нему можно было добавлять любую функциональность. Это вот общие слова. В частности, иметь унифицированный способ создания и управления программными объектами. По поводу создания все достаточно понятно - фабрика в этом поможет. А вот по поводу управления как раз и возникли некоторые замешательства.
Приведу пример. Изначально приложение без авторизации. Содержимое демонстриреутся всем, кто хочет. Потом решили добавить еще некоторое содержимое, которое требует авторизации. То есть, надо создать еще некоторый набор классов авторизации и органично их вписать. Допустим, все ограничится введением класса типа CUser. Экземпляр этого класса будет _единственным_ (одиночка), а кроме того, его надо будет сохранять в сессии и при необходимости распаковывать.
При той структуре, которая у меня вырисовалась на данном этапе исследования, эти два требования можно удовлетворить следующим образом:

class Cuser extends CClass{
   const singleton = true;
   const serializable = true;
}

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

 

[tony2001]

ага.
>Скорее всего, сумбурно и с упущениями.
нет, пример ясен, ага.

напрашивается такой вариант:

/* общий родитель для всех */
class Common {
/* значения по дефолту */
  protected $serializable = false;
  protected $singleton    = false;

  function isSingleton() {
	  return $this->singleton;
  }

  function isSerializable() {
	  return $this->serializable;
  }
}


class User extends Common {
  protected $serializable = true;
  protected $singleton    = true;

}

$user = new User;
$user->isSerializable();

 

[smokemaker]

А как по классу узнать, можно их сериализовывать или нет?

 

[tony2001]

ты же говорил, что у тебя _экземпляр_ будет, вроде бы.
спрашивать ты это будешь у экземпляра или у класса?
ты ведь не классы сериализовать будешь, ага?

 

[smokemaker]

Про сериализацию согласен. А насчет одиночки. Вот пришел в фабрику запрос на создание объекта, а там уже надо решить, одиночка он будет или нет. А если одиночка, то имеет смысл его поискать. Например, среди сериализованных в сессии.

 

[tony2001]

вот теперь да.
теперь я понял зачем это надо =)
ок, будем пробивать эту возможность.

 

[smokemaker]

Тогда уж заодно идеологический вопрос.
Чем объясняется то, что статические члены класса нельзя переопределять в потомках?
Интересует именно _идеологическая_ подоплека, если она, конечно, есть.