[PHP-DEV] RfC: rethink OO inheritance strictness
Michael Wallner
unfortunately I'm not very happy with the direction OO strictness takes
in PHP. I'm sure I'm not alone and many people second this feeling.
Precisely, let's have a look at the following:
mike@honeybadger:~/build/php-5.2-debug$ cli -d"error_reporting=8191" -r 'class c{function f(){}} class d extends c{function f($a){}}'
Strict Standards: Declaration of d::f() should be compatible with that of c::f() in Command line code on line 1
mike@honeybadger:~/build/php-unicode-debug$ cli -d"error_reporting=8191" -r 'class c{function f(){}} class d extends c{function f($a){}}'
Fatal error: Declaration of d::f() must be compatible with that of c::f() in Command line code on line 1
I *really* think that this enforcements are no good idea and
I _beg_ you that we leave this "area" to interfaces.
Regards,
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Smith
> Hi (Marcus),
>
> unfortunately I'm not very happy with the direction OO strictness takes
> in PHP. I'm sure I'm not alone and many people second this feeling.
>
>
> Precisely, let's have a look at the following:
>
> mike@honeybadger:~/build/php-5.2-debug$ cli -d"error_reporting=8191" -r
> 'class c{function f(){}} class d extends c{function f($a){}}'
> Strict Standards: Declaration of d::f() should be compatible with that
> of c::f() in Command line code on line 1
>
> mike@honeybadger:~/build/php-unicode-debug$ cli -d"error_reporting=8191"
> -r 'class c{function f(){}} class d extends c{function f($a){}}'
> Fatal error: Declaration of d::f() must be compatible with that of
> c::f() in Command line code on line 1
>
>
> I *really* think that this enforcements are no good idea and
> I _beg_ you that we leave this "area" to interfaces.
Aternatively there has been the idea of a flag to mark classes that are
to follow stricter rules.
regards,
Lukas
Richard Quadling
right. The methods (and the parameters) it has are part of that class.
If they overwrite a parent class's method, then fine. Instance of
either class would have different parameters for the same named
method.
If the sub class needs to call the parent then it can using parent::method();
On 21/07/06, Michael Wallner <mi...@php.net> wrote:
> Hi (Marcus),
>
> unfortunately I'm not very happy with the direction OO strictness takes
> in PHP. I'm sure I'm not alone and many people second this feeling.
>
>
> Precisely, let's have a look at the following:
>
> mike@honeybadger:~/build/php-5.2-debug$ cli -d"error_reporting=8191" -r 'class c{function f(){}} class d extends c{function f($a){}}'
> Strict Standards: Declaration of d::f() should be compatible with that of c::f() in Command line code on line 1
>
> mike@honeybadger:~/build/php-unicode-debug$ cli -d"error_reporting=8191" -r 'class c{function f(){}} class d extends c{function f($a){}}'
> Fatal error: Declaration of d::f() must be compatible with that of c::f() in Command line code on line 1
>
>
> I *really* think that this enforcements are no good idea and
> I _beg_ you that we leave this "area" to interfaces.
>
>
> Regards,
> --
> Michael
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Mike Bretz
Michael Wallner wrote:
> mike@honeybadger:~/build/php-unicode-debug$ cli
> -d"error_reporting=8191" -r 'class c{function f(){}} class d extends
> c{function f($a){}}'
> Fatal error: Declaration of d::f() must be compatible with that of
> c::f() in Command line code on line 1
>
>
> I *really* think that this enforcements are no good idea and I _beg_
> you that we leave this "area" to interfaces.
+1
In real live "C++" world I often have parent classes with function f()
and an extended class which also uses the function name f(..) but with
other, possibly class specific, variables, which then calls parent
f()... I do not see a good reason to enforce that both functions must be
exactly the same when extending, especially since c::f() does not get
called automatically, _when_ overwriting it in class d.
mike
--
mike peter bretz metropolis ag / entwicklung
email: m.b...@metropolis-ag.de heinestraße 72
phone: +49-7121-348-120 d-72762 reutlingen
fax: +49-7121-348-111 http://www.metropolis-ag.de/
metropolis ag. creating social internetworks.
Derick Rethans
> Richard Quadling wrote:
> > I agree with this point. The sub class is a valid entity in its own
> > right. The methods (and the parameters) it has are part of that class.
> > If they overwrite a parent class's method, then fine. Instance of
> > either class would have different parameters for the same named
> > method.
>
> Its not about being "right". Acedemically Marcus changes are correct. The
> question is just if we want to force this way of working onto PHP, or if it
> makes more sense to make it optional.
I would say that if you want to use it in the "wrong" lenient way that
you need to mark your classes as such and not the other way around. This
might also have the effect that people see PHP as a better language
(because of the OO stuff is "correct" by default.
regards,
Derick
Derick Rethans
> Michael Wallner wrote:
> > mike@honeybadger:~/build/php-unicode-debug$ cli
> > -d"error_reporting=8191" -r 'class c{function f(){}} class d extends
> > c{function f($a){}}'
> > Fatal error: Declaration of d::f() must be compatible with that of
> > c::f() in Command line code on line 1
> >
> >
> > I *really* think that this enforcements are no good idea and I _beg_
> > you that we leave this "area" to interfaces.
> +1
>
> In real live "C++" world I often have parent classes with function f()
> and an extended class which also uses the function name f(..) but with
> other, possibly class specific, variables, which then calls parent
> f()... I do not see a good reason to enforce that both functions must be
> exactly the same when extending, especially since c::f() does not get
> called automatically, _when_ overwriting it in class d.
It's quite a different thing in C++ as there you have method overloading
which PHP doesn't have. Therefore your argument doesn't hold here as
they are simply *two different* methods, and not an overriden one. In
your code that uses the derived class you can still use both methods
(one without, and the one with parameters).
Lukas Smith
> On Fri, 21 Jul 2006, Lukas Smith wrote:
>
>> Richard Quadling wrote:
>>> I agree with this point. The sub class is a valid entity in its own
>>> right. The methods (and the parameters) it has are part of that class.
>>> If they overwrite a parent class's method, then fine. Instance of
>>> either class would have different parameters for the same named
>>> method.
>> Its not about being "right". Acedemically Marcus changes are correct. The
>> question is just if we want to force this way of working onto PHP, or if it
>> makes more sense to make it optional.
>
> I would say that if you want to use it in the "wrong" lenient way that
> you need to mark your classes as such and not the other way around. This
> might also have the effect that people see PHP as a better language
> (because of the OO stuff is "correct" by default.
Or it will mean that the established user base gets ticked off and the
other people see PHP as just playing catch up to Java. Now is probably
the time to hire a consulting firm ;)
regards,
Lukas
Richard Quadling
I suppose the main issue is that userland sees OOP and expects things
to be similar to other OOPs they've used. They're blinkered as to why
it ISN'T the same! Like discrete setters/getters providing
accesssibilty or being able to promote/demote visibility via
inheritence.
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
Soenke Ruempler
11:31 AM:
> It's quite a different thing in C++ as there you have method
> overloading which PHP doesn't have. Therefore your argument doesn't
Exactly the point. It's parameter polymorphism in C++/Java.
> hold here as they are simply *two different* methods, and not an
> overriden one. In your code that uses the derived class you can still
> use both methods (one without, and the one with parameters).
To be compatible, the only thing you have to do is adding standard
values to derived methods' parameters:
$ php -d"error_reporting=3D8191" -r 'class c{function f(){}} class d
extends c{function f($a){}}';
Strict Standards: Declaration of d::f() should be compatible with that
of c::f() in Command line code on line 2
$ php -d"error_reporting=3D8191" -r 'class c{function f(){}} class d
extends c{function f($a =3D null){}}';
$ [no error]
This behaviour makes sense to me.
-soenke
Richard Quadling
be allowed different parameter signatures. If you want to extend a
method but hide original implementation, you can't change the
parameter signature. I'm on the opposite side of the fence to you it
seems!
On 21/07/06, Soenke Ruempler <ruem...@topconcepts.com> wrote:
> Derick Rethans <mailto:der...@php.net> wrote on Friday, July 21, 2006
> 11:31 AM:
>
> To be compatible, the only thing you have to do is adding standard
> values to derived methods' parameters:
>
> $ php -d"error_reporting=8191" -r 'class c{function f(){}} class d
> extends c{function f($a){}}';
>
> Strict Standards: Declaration of d::f() should be compatible with that
> of c::f() in Command line code on line 2
>
> $ php -d"error_reporting=8191" -r 'class c{function f(){}} class d
> extends c{function f($a = null){}}';
> $ [no error]
>
> This behaviour makes sense to me.
>
> -soenke
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
Daine Mamacos
with all methods?
-----Original Message-----
From: Derick Rethans [mailto:der...@php.net]
Sent: 21 July 2006 10:31
To: Mike Bretz
Cc: inte...@lists.php.net
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
On Fri, 21 Jul 2006, Mike Bretz wrote:
> Michael Wallner wrote:
> > mike@honeybadger:~/build/php-unicode-debug$ cli
> > -d"error_reporting=8191" -r 'class c{function f(){}} class d extends
> > c{function f($a){}}'
> > Fatal error: Declaration of d::f() must be compatible with that of
> > c::f() in Command line code on line 1
> >
> >
> > I *really* think that this enforcements are no good idea and I _beg_
> > you that we leave this "area" to interfaces.
> +1
>
> In real live "C++" world I often have parent classes with function f()
> and an extended class which also uses the function name f(..) but with
> other, possibly class specific, variables, which then calls parent
> f()... I do not see a good reason to enforce that both functions must be
> exactly the same when extending, especially since c::f() does not get
> called automatically, _when_ overwriting it in class d.
It's quite a different thing in C++ as there you have method overloading
which PHP doesn't have. Therefore your argument doesn't hold here as
they are simply *two different* methods, and not an overriden one. In
your code that uses the derived class you can still use both methods
(one without, and the one with parameters).
Derick
Richard Quadling
On 21/07/06, Daine Mamacos <scu...@reverseorder.net> wrote:
> If a constructor gets overridden, why should it not be the same behaviour
> with all methods?
>
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
Soenke Ruempler
b24gRnJpZGF5LCBKdWx5DQoyMSwgMjAwNiAxMjoyOCBQTToNCg0KPiBTaG91bGRuJ3QgYmUgbmVj
ZXNzYXJ5LiBBcyB0aGVyZSBhcmUgMiBkaWZmZXJlbnQgbWV0aG9kcywgdGhleSBzaG91bGQNCj4g
YmUgYWxsb3dlZCBkaWZmZXJlbnQgcGFyYW1ldGVyIHNpZ25hdHVyZXMuIElmIHlvdSB3YW50IHRv
IGV4dGVuZCBhDQo+IG1ldGhvZCBidXQgaGlkZSBvcmlnaW5hbCBpbXBsZW1lbnRhdGlvbiwgeW91
IGNhbid0IGNoYW5nZSB0aGUNCj4gcGFyYW1ldGVyIHNpZ25hdHVyZS4gSSdtIG9uIHRoZSBvcHBv
c2l0ZSBzaWRlIG9mIHRoZSBmZW5jZSB0byB5b3UgaXQNCj4gc2VlbXMhIA0KDQpCdXQgdGhhdCdz
IG5vdCB0aGUgbmF0dXJlIG9mIHBvbHltb3JwaGlzbSBhbmQgdGhlIHByZWRpY3RuZXNzIGFuZA0K
Y29uc2lzdGVuY3kgb2YgYW4gQVBJLiBGb3IgZXhhbXBsZSAtIHRoaW5rIG9mIG9iamVjdCBhZ2dy
ZWdhdGlvbjoNCg0KcHVibGljIGZ1bmN0aW9uIHNldEJsdWIoQSAkYSkgew0KCSR0aGlzLT5fYSA9
ICRhOw0KfQ0KDQpOb3cgYmVjYXVzZSBvZiBteSBjb25zaXN0ZW50IEFQSSBvZiBjbGFzcyBBIGFu
ZCBhbGwgZGVyaXZlZCBjbGFzc2VzIEkNCmV4YWN0bHkga25vdyB0aGUgbWV0aG9kcyBhbmQgcGFy
YW1ldGVycywgZXZlbiBpZiBCIChhcyBjaGlsZCBjbGFzcyBvZiBBKQ0KaXMgcGFzc2VkIHRvICJz
ZXRCbHViKCkiLg0KDQpTbyBtYXliZSBmcm9tIHlvdXIgUE9WIGl0J3MgdHdvIGRpZmZlcmVudCBt
ZXRob2RzIChhbmQgeWVzLCBpdCBJUw0KKnRlY2huaWNhbGx5KikuIEJ1dCBmcm9tIE9PUCBhbmQg
QVBJIGRlc2lnbiB2aWV3IGl0IGlzIHBvbHltb3JwaGlzbSBhbmQNCmNvbnNpc3RlbmN5LCBpZiBJ
IGRpZG4ndCBmYWlsZWQgYWxsIE9PUCBsZXNzb25zIGFuZCBkZXNpZ24gcGF0dGVybiBib29rcw0K
OykNCg0KLXNvZW5rZQ0K
Pierre
mi...@php.net (Michael Wallner) wrote:
> Hi (Marcus),
>
> unfortunately I'm not very happy with the direction OO strictness
> takes in PHP. I'm sure I'm not alone and many people second this
> feeling.
>
>
> Precisely, let's have a look at the following:
>
> mike@honeybadger:~/build/php-5.2-debug$ cli -d"error_reporting=8191"
> -r 'class c{function f(){}} class d extends c{function f($a){}}'
> Strict Standards: Declaration of d::f() should be compatible with
> that of c::f() in Command line code on line 1
>
> mike@honeybadger:~/build/php-unicode-debug$ cli
> -d"error_reporting=8191" -r 'class c{function f(){}} class d extends
> c{function f($a){}}' Fatal error: Declaration of d::f() must be
> compatible with that of c::f() in Command line code on line 1
>
>
> I *really* think that this enforcements are no good idea and
> I _beg_ you that we leave this "area" to interfaces.
I second your opinion. I don't see anything wrong in this code. PHP
was never thought as an academic language, neither to clone pure OO
language.
Without starting a java/php fud, but let continue down this way and we
will drop the reasons why we are the web language #1 and not java.
Cheers,
-- Pierre
Jared Williams
> Hi (Marcus),
>
> unfortunately I'm not very happy with the direction OO
> strictness takes
> in PHP. I'm sure I'm not alone and many people second this feeling.
>
>
> Precisely, let's have a look at the following:
>
> mike@honeybadger:~/build/php-5.2-debug$ cli
> -d"error_reporting=8191" -r 'class c{function f(){}} class d
> extends c{function f($a){}}'
> Strict Standards: Declaration of d::f() should be compatible
> with that of c::f() in Command line code on line 1
>
> mike@honeybadger:~/build/php-unicode-debug$ cli
> -d"error_reporting=8191" -r 'class c{function f(){}} class d
> extends c{function f($a){}}'
> Fatal error: Declaration of d::f() must be compatible with
> that of c::f() in Command line code on line 1
>
>
> I *really* think that this enforcements are no good idea and
> I _beg_ you that we leave this "area" to interfaces.
>
Not sure why this is necessary, why doesn't
Class C
{
function f() { }
}
Class D
{
private $c;
function __construct(C $c) { $this->c = $c; }
function f($a) { }
}
work, with PHP's duck typing?
Jared
Ron Korving
(I realize that that would remove the possibility to define a fallback
function in the parent class though.)
- Ron
""Soenke Ruempler"" <ruem...@topconcepts.com> schreef in bericht
news:EDB0F034E395BF4284D...@sky.stade.topconcepts.net...
> Richard Quadling <mailto:rqua...@googlemail.com> wrote on Friday, July
> 21, 2006 12:28 PM:
>
>> Shouldn't be necessary. As there are 2 different methods, they should
>> be allowed different parameter signatures. If you want to extend a
>> method but hide original implementation, you can't change the
>> parameter signature. I'm on the opposite side of the fence to you it
>> seems!
>
> But that's not the nature of polymorphism and the predictness and
> consistency of an API. For example - think of object aggregation:
>
> public function setBlub(A $a) {
> $this->_a = $a;
> }
>
> Now because of my consistent API of class A and all derived classes I
> exactly know the methods and parameters, even if B (as child class of A)
> is passed to "setBlub()".
>
> So maybe from your POV it's two different methods (and yes, it IS
> *technically*). But from OOP and API design view it is polymorphism and
> consistency, if I didn't failed all OOP lessons and design pattern books
> ;)
>
> -soenke
Richard Quadling
a descendent of the class A.
But that doesn't mean that class B is the same as class A.
With overloading, the parameter signature is used to determine which
method is used. The method has to exist within the class heirarchy.
This is what I think the point is.
If I can use a different constructor parameter signature, why can't I
use a different method parameter signature?
They ARE 2 methods! One hides the other. Even if the method's
parameter signature is identical.
If method X is in both class A and class B, using just class B's
instance, you cannot get to class A's method X. Class B has to allow
access via parent::x();
So, why have the same signatures?
On 21/07/06, Stefan Walk <stefa...@gmail.com> wrote:
> It seems some people are missing the point of the error. "B is a
> subclass of A" means: everywhere you use A, you can use B instead.
> ($instance_of_B instanceof A returns true). So, you design a method of
> yours to accept a parameter of class A, it also accepts B. But if the
> method signature (number of required parameters) changes, that is not
> the case anymore. So, you break the inheritance contract, which means
> that you shouldn't have used inheritance after all.
>
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
Soenke Ruempler
b24gRnJpZGF5LCBKdWx5DQoyMSwgMjAwNiAxOjE2IFBNOg0KDQo+IEFoLiBJIHNlZSB0aGUgZGlm
ZmVyZW5jZS4gSSdtIGV4cGVjdGluZyBvdmVybG9hZGluZy4gSG1tbS4gRXZlbiB3aXRoDQo+IHRo
YXQgdGhvdWdoLCBvdmVybG9hZGluZyBpcyB0aGUgZGVzaXJlZCBlZmZlY3QuDQoNCkJ1dCBQSFAg
aGFzIG5vIHBhcmFtZXRlciBvdmVybG9hZGluZywgb25seSBvdmVybG9hZGluZyB3aXRoIGludGVy
Y2VwdG9yDQptZXRob2RzLiBJTUhPIHdoYXQgeW91IGRvIGlzICJtaXN1c2luZyIgT09QIHBvbHlt
b3JwaGlzbSBhcyBwYXJhbWV0ZXINCm92ZXJsb2FkaW5nLiBGb3IgY2xlYXJuZXNzIG9mIHlvdXIg
Y2xhc3MgaW50ZXJmYWNlIC8gcHVibGljIEFQSSwgd2h5DQpkb24ndCB5b3UganVzdCB1c2UgYW5v
dGhlciBtZXRob2QgdGhhdCBhY2NlcHRzIG90aGVyIHBhcmFtZXRlcnMgdGhhbiB0aGUNCnBhcmVu
dCdzIG9uZS4NCg0KQW5vdGhlciBwb3NzaWJpbHR5IC8gd29ya2Fyb3VuZCBpcyBubyBtZXRob2Qg
cGFyYW1ldGVycyBpbiBkZWNsYXJhdGlvbg0KYW5kIHRvIHVzZSBmdW5jX2dldF9hcmdzKCkuDQoN
Ci1zb2Vua2UNCg==
Richard Quadling
that though, overloading is the desired effect.
On 21/07/06, Soenke Ruempler <ruem...@topconcepts.com> wrote:
> Richard Quadling <mailto:rqua...@googlemail.com> wrote on Friday, July
> 21, 2006 12:28 PM:
>
> > Shouldn't be necessary. As there are 2 different methods, they should
> > be allowed different parameter signatures. If you want to extend a
> > method but hide original implementation, you can't change the
> > parameter signature. I'm on the opposite side of the fence to you it
> > seems!
>
> But that's not the nature of polymorphism and the predictness and
> consistency of an API. For example - think of object aggregation:
>
> public function setBlub(A $a) {
> $this->_a = $a;
> }
>
> Now because of my consistent API of class A and all derived classes I
> exactly know the methods and parameters, even if B (as child class of A)
> is passed to "setBlub()".
>
> So maybe from your POV it's two different methods (and yes, it IS
> *technically*). But from OOP and API design view it is polymorphism and
> consistency, if I didn't failed all OOP lessons and design pattern books
> ;)
>
> -soenke
>
Richard Quadling
changed. I'm just saying that overloading would be a valid solution.
On 21/07/06, Soenke Ruempler <ruem...@topconcepts.com> wrote:
> Richard Quadling <mailto:rqua...@googlemail.com> wrote on Friday, July
> 21, 2006 1:16 PM:
>
> > Ah. I see the difference. I'm expecting overloading. Hmmm. Even with
> > that though, overloading is the desired effect.
>
> But PHP has no parameter overloading, only overloading with interceptor
> methods. IMHO what you do is "misusing" OOP polymorphism as parameter
> overloading. For clearness of your class interface / public API, why
> don't you just use another method that accepts other parameters than the
> parent's one.
>
> Another possibilty / workaround is no method parameters in declaration
> and to use func_get_args().
Derick Rethans
> Derick Rethans <mailto:der...@php.net> wrote on Friday, July 21, 2006
> 11:31 AM:
>
> > It's quite a different thing in C++ as there you have method
> > overloading which PHP doesn't have. Therefore your argument doesn't
>
> Exactly the point. It's parameter polymorphism in C++/Java.
>
> > hold here as they are simply *two different* methods, and not an
> > overriden one. In your code that uses the derived class you can still
> > use both methods (one without, and the one with parameters).
>
> To be compatible, the only thing you have to do is adding standard
> values to derived methods' parameters:
>
> $ php -d"error_reporting=8191" -r 'class c{function f(){}} class d
> extends c{function f($a){}}';
>
> Strict Standards: Declaration of d::f() should be compatible with that
> of c::f() in Command line code on line 2
>
> $ php -d"error_reporting=8191" -r 'class c{function f(){}} class d
> extends c{function f($a = null){}}';
> $ [no error]
>
> This behaviour makes sense to me.
Yes... and this is how C++ does it.
Derick
Michael Wallner
I wasn't talking about programming paradigms and correctly following them,
but about PHPs freedom it was so generously giving to me in the past.
A fatal error doesn't give me any freedom, no matter if it's totally
correct or not.
--
Michael
Marcus Boerger
first of all the decision never was my decision, second i am not going
to let peole run into problem hell. I coded enough PHP 4 OO to see that
it didn't make any sense and caused a lot of errors in the code we wrote
back then. But once again it is not my decision, i was not even my choice
of OO model. The only thing i might have to excuse myself for is that i
spent hundreds and hundreds of hours to get the oo code work at all and
yes i know that we still have problems. Nothing more to say here, go hunt
the guys that decide, not idiots devoting free time to make this all work.
best regards
marcus
p.s.: I am not a Java fan, infact i avoid it wherever possible.
Friday, July 21, 2006, 10:55:05 AM, you wrote:
> Hi (Marcus),
> unfortunately I'm not very happy with the direction OO strictness takes
> in PHP. I'm sure I'm not alone and many people second this feeling.
> Precisely, let's have a look at the following:
> mike@honeybadger:~/build/php-5.2-debug$ cli -d"error_reporting=8191" -r
> 'class c{function f(){}} class d extends c{function f($a){}}'
> Strict Standards: Declaration of d::f() should be compatible with that of
> c::f() in Command line code on line 1
> mike@honeybadger:~/build/php-unicode-debug$ cli -d"error_reporting=8191"
> -r 'class c{function f(){}} class d extends c{function f($a){}}'
> Fatal error: Declaration of d::f() must be compatible with that of c::f() in Command line code on line 1
> I *really* think that this enforcements are no good idea and
> I _beg_ you that we leave this "area" to interfaces.
> Regards,
> --
> Michael
Best regards,
Marcus
Andi Gutmans
Inherited classes should adhere to the instanceof operator. Meaning that if
you get an object you can check if it's an instance of another class and if
so, you can call it *exactly* the way you could the parent class. This
allows for good polymorphic design in applications. Allowing subclasses to
change a function's signature to be incompatible with its parent would break
this rule (you can use default arguments to resolve some of these cases as
instanceof remains).
For constructors it actually makes sense because at the time of
instantiaton, you know what the concrete class is. It is very common for
constructors to be very much different in polymorphic classes.
Andi
> -----Original Message-----
> From: Richard Quadling [mailto:rqua...@googlemail.com]
> Sent: Friday, July 21, 2006 3:43 AM
> To: inte...@lists.php.net
> Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
>
> Exactly. Consistency.
>
> On 21/07/06, Daine Mamacos <scu...@reverseorder.net> wrote:
> > If a constructor gets overridden, why should it not be the same
> > behaviour with all methods?
> >
> --
> -----
> Richard Quadling
> Zend Certified Engineer :
> http://zend.com/zce.php?c=ZEND002498&r=213474731
> "Standing on the shoulders of some very clever giants!"
>
Michael Wallner
> There's a big difference. Inherited classes should adhere to the
> instanceof operator. Meaning that if you get an object you can check
> if it's an instance of another class and if so, you can call it
> *exactly* the way you could the parent class. This allows for good
> polymorphic design in applications. Allowing subclasses to change a
> function's signature to be incompatible with its parent would break
> this rule (you can use default arguments to resolve some of these
> cases as instanceof remains). For constructors it actually makes
> sense because at the time of instantiaton, you know what the concrete
> class is. It is very common for constructors to be very much
> different in polymorphic classes.
This is only partly true. In languages where you can be sure to call A::f()
this is useful. You suggest to change PHP, which doesn't have any other means
for decent overloading, in a way that completely removes this freedom.
Using interfaces is IMHO the way to enforce method signature in PHP.
If there are no other evidences I cannot understand this design move.
--
Michael
Robert Cummings
> Andi Gutmans wrote:
> > There's a big difference. Inherited classes should adhere to the
> > instanceof operator. Meaning that if you get an object you can check
> > if it's an instance of another class and if so, you can call it
> > *exactly* the way you could the parent class. This allows for good
> > polymorphic design in applications. Allowing subclasses to change a
> > function's signature to be incompatible with its parent would break
> > this rule (you can use default arguments to resolve some of these
> > cases as instanceof remains). For constructors it actually makes
> > sense because at the time of instantiaton, you know what the concrete
> > class is. It is very common for constructors to be very much
> > different in polymorphic classes.
>
> This is only partly true. In languages where you can be sure to call A::f()
> this is useful. You suggest to change PHP, which doesn't have any other means
> for decent overloading, in a way that completely removes this freedom.
> Using interfaces is IMHO the way to enforce method signature in PHP.
I'd have to agree. PHP4 had the nice flexibility of allowing subclasses
to override the method signature without incurring the wrath of an
error. PHP 5 and all it's OOP sugar said screw that, we're going to give
you interfaces AND we're going to tie your hands behind your back, even
when you choose not to use an interface, and make you do redundant
things like re-iterate all the default values the subclass declared when
overriding it... and depending on the level of inheritance this
redundancy travels all the way up the ancestry... YUCK. Seriously, the
name interface implies a forced pattern... if you want to force a
signature, force it when an interface is implemented.
So anyways, while we're all chatting :) How about prototype style
override support *cackles, ducks, and runs*.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'