Re: Abstract properties

2012.12.01. 13:35, "Sebastian Krebs" <krebs.seb@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.