2012.12.01. 13:35, "Sebastian Krebs" <krebs....@gmail.com> ezt írta:
>
> Hi,
>
> Don't want to start a big discussion, but is there a concrete reason, why
> abstract properties (or "a kind of abstract") are not supported? I've
> learned, that "an interface [the concept, not the implementations within a
> language] is the sum of all accessible (--> public) methods and
> properties", what as far as I understand means, that properties could (and
> should) be defineable in concrete interfaces too
>
> interface Queue {
> public function enqueue($value);
> public function dequeue();
> public $top;
> }
> // or
> abstract class Queue {
> abstract public function enqueue($value);
> abstract public function dequeue();
> abstract public $top;
> }
>
> Of course in the second example the "abstract" is kind of useless, but
it's
> for illustration. I've seen some cases (for example the example above),
> where it would be useful to define properties in interfaces, but instead I
> was forced to (in my eyes) misuse [1] methods. Right now I cannot safely
> write somethig like
>
> /**
> * Must have a $top property
> */
> interface Queue {
> public function enqueue($value);
> public function dequeue();
> }
>
> function foo(Queue $q) {
> doSomethingWithTop($q->top);
> }
>
> Because I can never ensure, that $top exists. I always have to work with
> isset() here (or of course I use a getter, as mentioned earlier), what
> takes a little bit from the "usefulness" of interfaces ^^ The interface
> feels incomplete.
>
> Would like to hear some opinions, or maybe a summary of earlier
discussions
> about this topic :)
>
> Regards,
> Sebastian
>
>
>
>
> [1] I've also learned, that methods define behaviour and properties define
> the state. "$top" in the example is part of the state, thus calling a
> method to fetch the state feels wrong/like a hack (thats btw my opinion
> about getters/setters too; just to create a bridge to other concepts ;)).
>
> --
> github.com/KingCrunch
I'm also interested about the rationale behind this design decision.
