Note: this post contains a 'complaint' but its not aimed
at any one in particular, especially not Rasmus as he doesn't give
the impression of being much of an OO proponent at heart, and because
he repeatly seems to err on the side of practicality and caution
(as opposed to correctness for correctness-sake).
Rasmus Lerdorf wrote:
Matthias Pigulla wrote:
...
The point is that interfaces are nothing you could anything with - that
is, if you have "something" that implements an interface, it has already
been constructed. You never construct instances through an interface
(you would have to choose an implementation, the interface isn't one)...
I just cannot explain it in a better way ;) It's somewhat similar to
that you cannot make static calls on interfaces.
I don't see why you can't specify that a class definition must have a
constructor. Obviously the constructor is not for the interface itself.
so I can only assume that the ability to declare ctor signatures have been left
in
because they do no harm regardless of whether it is 'correct'.
so what was the harm in leaving in the ability to declare interface methods
as protected (or even private)?
ctor declarations in interfaces are just as wrong as protected method
declarations
(or static method declaration - although they seem to be allowed also - I can't
remember
if this was always allowed or whether this was reinstated at some point)
according to
the 'fundamental truth' regarding interfaces (they only make sense in a object
context)
that has been repeated here many times over.
bottom line I am begging for consistency and easy of use: please
reinstate the ability to be able to declare something like:
interface ImCrazy
{
abstract static protected function __construct(CrazySettings $s,
CrazyView $v);
}
and if not then I'd be much obliged if someone could point out why non-correct
non-harmful
ability has been added with regard to interfaces and another equally
non-correct non-harmful
ability has been removed. understanding why goes along way to acceptance -
which boils down
to public perception issues once again.
rgds,
Jochem
** ofcourse if something is technically impossible at the php/zend engine level
or if its a very hard to implement edge case situation I can conceed that the
break/change/whatever may well have to occur for the sake of
practicality/maintainability
at a deeper level. making such reasoning clear to lesser mortals is still highly
recommended in order to mitigate unnecessary irritation on both sides of the
field.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
