Marcus Boerger wrote:
> Hello Pierre,
>
> Monday, August 7, 2006, 11:36:57 AM, you wrote:
>
>> On Mon, 7 Aug 2006 11:16:05 +0200
>> [EMAIL PROTECTED] (Pierre) wrote:
>
>>>> <thinking>Oh thinking and documenting is forbidden - i
>>>> see</thinking>
>>> PHP thinks for me now, and if it is about documenting, then I don't
>>> any interfaces and all the other additions, I can document everything.
>
>> Sorry, I mean I do not _need_ any of the new OO additions (private,
>> public, interface, etc...) as everything can be documented.
>
> Some people have colleagues, sometimes self discipline is not enough.
> And yes you can leave public, protected and private. But that is not
> even in any remote way connected the topic.
I had a [another] thought about the enforced strictness issue being
discussed...
the current thinking of Marcus (and his proponents) is that method signatures
must stay the same when a method is overloaded in a subclass, making std.
class signatures work exactly in the way that interface signatures work.
Pierre (and his proponents) think that this is an artificial limitation which
in the general case make php less attractive.
I am personally in the 'Pierre camp' on this one but I understand the
argument Marcus provides regarding breaking the 'is a' relationship.
(btw: I am aware of both Marcus' and Pierre's great work in the php project
and am grateful for their efforts; regardless of whether I always agree with
their personal vision of what php is and where it should be headed)
My Ideas:
=========
idea no. 1 is: to make it so that methods originally defined as abstract to
behave like methods defined in interfaces (namely enforce strict method
signature
compliance - continue using E_FATAL for non-compatibility); and leave methods
which are not derived from an abstract definition to change their signatures
without
any penalty (not even E_STRICT). I realise that this may not do the trick for
the
strictness camp because it might not always be possible/viable to define the
required abstract method in order to enforce method signature strictness.
idea no. 2 is: to reuse the 'interface' keyword in another context, namely as
a modifier for the method definition; the idea being that any method that
overloads
a method in a baseclass that is defined as 'interface' must adhere to the
original
method signature (again using an E_FATAL for non-compatibility). obviously
doing something
like this requires hashing out the details of, for instance, what happens when
you don't
specify 'interface' for a base class method but do specify it for a subclass's
overload of
said method and/or whether the interface modifier need be specified in
overloaded methods (etc).
e.g:
class Foo {
public interface function myFoo($x) { echo $x; } // strict method
signature enforced
}
class Bar extends Foo {
public function myFoo() { echo "bar"; } // this would be E_FATAL
}
class Qux extends Foo {
public interface function myFoo($x) { echo $x; } // this is okay.
}
rgds,
Jochem
>
>> -- Pierre
>
>
>
>
> Best regards,
> Marcus
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
