Hello Jochem,
Monday, August 7, 2006, 12:15:51 PM, you wrote:
> 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.
> }
Hmm i see some elegance here :-)
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
