Marcus Boerger wrote:
Hello Christian,
Thursday, August 25, 2005, 12:17:25 PM, you wrote:
Jochem Maas wrote:
I would see this as a optional addition to the syntax of interfaces...
i.e. everything works as before but you can add default function bodies
which would behave as if it was defined in each class that implements
the given interface.
if this is a truely evil concept I would very much appreciate a little
heads up as to why :-)
One quick thing which comes to mind the the WTF-factor when you
implement two different interfaces with two different base
implementations. One of the cruxes of multiple inheritance.
There is no real problem here only probably naming confusion with the
coder and all its classes. And of course the problem that later changes
might lead to errors due to changes in order.
That said there are two things about this:
1) why not offer static methods with bodies in interfaces that don't get
inherited.
2) do not inherit any body from interfaces, thus you'd need to call them
explicitly.
this would certainly cover my original thought/mindburp regarding code reuse
with respect to simple/repeated interface implementation. at any rate MI is
not something I'm looking for as a 'simple phper' :-) I might change my mind
if and when I ever properly get to grips with a language like C++.
I can also imagine that use of the $this keyword might be problematic ,if
not from an internals POV, possible from a phper's POV rather like the scope of
$this confuses people when calling static methods from inside non-static methods
regardless, interesting times ahead for php... thanks for everything!
Thus our MI problems are still solved.
The real MI problems are anyway related to virtual inheritance....
The question is, does this help us or is it only making things more
complicated to understand?
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
