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 ;)).
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 toointerface 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 ;)).
I'm also interested about the rationale behind this design decision.
I'm also interested about the rationale behind this design decision.
Just for the record, this would have been one of the things that the
accessors proposal would have added.
Here here. :)
I'm also interested about the rationale behind this design decision.
Just for the record, this would have been one of the things that the
accessors proposal would have added.
--
-Clint
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?
Hi,
The reason for not having abstract properties is that when you are defining a type you don't care about how the implementation will store the state. The contract is about message exchanges, how the objects will talk to each other, via the public interface, e.g. the public methods.
Also, think of the keyword "abstract" as something that is incomplete. An abstract class is an incomplete class, an abstract method is an incomplete method. So an abstract property doesn't make sense, as it doesn't need anything to be complete.
Reinforce the implementation to store state in a particular way would be a bad feature for PHP. This is one the things we got it right.
Kind regards,
Marcello