# RfC: rethink OO inheritance strictness
- Thread: https://externals.io/message/24804
- Original archive: https://news-web.php.net/php.internals/24804
- Started by Michael Wallner on 2006-07-21T08:55:05+00:00
- Messages: 108
- Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/24804.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #24804 — Michael Wallner — 2006-07-21T08:55:05+00:00
URL: https://externals.io/message/24804#24804
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
---
## #24805 — Lukas Smith — 2006-07-21T09:04:43+00:00
URL: https://externals.io/message/24804#24805 · In reply to: #24804
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.
Aternatively there has been the idea of a flag to mark classes that are
to follow stricter rules.
regards,
Lukas
---
## #24806 — Richard Quadling — 2006-07-21T09:08:29+00:00
URL: https://externals.io/message/24804#24806 · In reply to: #24804
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.
If the sub class needs to call the parent then it can using parent::method();
> 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
>
> --
>
>
>
>
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
---
## #24809 — Lukas Smith — 2006-07-21T09:18:26+00:00
URL: https://externals.io/message/24804#24809 · In reply to: #24806
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.
regards,
Lukas
---
## #24811 — Derick Rethans — 2006-07-21T09:29:07+00:00
URL: https://externals.io/message/24804#24811 · In reply to: #24809
> Richard Quadling wrote:
> > […]
>
> 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
---
## #24812 — Derick Rethans — 2006-07-21T09:30:34+00:00
URL: https://externals.io/message/24804#24812
> Michael Wallner wrote:
> > […]
> +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
---
## #24813 — Lukas Smith — 2006-07-21T09:32:33+00:00
URL: https://externals.io/message/24804#24813 · In reply to: #24811
Derick Rethans wrote:
>
>
> > […]
>
> 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
---
## #24814 — Richard Quadling — 2006-07-21T09:38:08+00:00
URL: https://externals.io/message/24804#24814 · In reply to: #24813
I see it as catch up to OOP. I've never used Java. I've used Delphi though.
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.
> Derick Rethans wrote:
> > […]
>
> 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
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
---
## #24820 — Pierre — 2006-07-21T10:46:13+00:00
URL: https://externals.io/message/24804#24820 · In reply to: #24804
On Fri, 21 Jul 2006 10:55:05 +0200
mike@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
---
## #24821 — Jared Williams — 2006-07-21T11:20:00+00:00
URL: https://externals.io/message/24804#24821 · In reply to: #24804
> 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
---
## #24844 — Michael Wallner — 2006-07-21T15:03:17+00:00
URL: https://externals.io/message/24804#24844 · In reply to: #24804
Hi all,
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
---
## #24849 — Marcus Boerger — 2006-07-21T17:25:39+00:00
URL: https://externals.io/message/24804#24849 · In reply to: #24804
Hello Michael,
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
---
## #25081 — Richard Lynch — 2006-08-01T17:38:10+00:00
URL: https://externals.io/message/24804#25081 · In reply to: #24813
> Derick Rethans wrote:
> > […]
[snip]
> > […]
With all due respect...
There are several languages in which it's not "right" at all.
Whether PHP wants to move more in one direction or another, or cut its
own path and stand on its own merits is the question *I* see at issue
here.
Are we aiming to be "just like Java" (tm) or are we going more towards
some spices tossed in from, say, Common Lisp / Scheme, to create
something new?
Are we aiming towards polymorphism in PHP 7? (or 8, or 9, or ???)
What will it look like?
> 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 ;)
I use OOP so seldom that I just don't care *that* much, but if I'm
ever going to actually use this stuff, I'd rather *not* have PHP force
me to not use different args on the "same" methods in subclasses.
--
Like Music?
http://l-i-e.com/artists.htm
---
## #25083 — Richard Lynch — 2006-08-01T18:49:04+00:00
URL: https://externals.io/message/24804#25083 · In reply to: #24812
>
>
> > […]
>
> 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).
So what exactly is the purpose of enforcing the same args here?
Does it make the C code under the hood simpler?
Does it make PHP an order of magnitude faster?
I'm honestly just sitting here asking myself WHY anybody wants this,
and not finding any benefit at all.
Obviously somebody somewhere thinks it's a Good Idea for some reason.
Is this how Java works, and the reasoning is to be more like Java?
Is it just an Ideal that any given method should always take the same
args in the "keep it simple stupid" idealogy (sp?) of PHP?
I don't have a "problem" with these answers: I truly just want to
understand the driving motive behind PHP's direction in OOP choices.
Thanks for any clarification.
--
Like Music?
http://l-i-e.com/artists.htm
---
## #25084 — Lukas Smith — 2006-08-01T20:33:24+00:00
URL: https://externals.io/message/24804#25084 · In reply to: #25083
Richard Lynch wrote:
> So what exactly is the purpose of enforcing the same args here?
>
> Does it make the C code under the hood simpler?
>
> Does it make PHP an order of magnitude faster?
>
> I'm honestly just sitting here asking myself WHY anybody wants this,
> and not finding any benefit at all.
I think this was stated before in this thread. The academic idea of OOP
is that children are essentially expanded variants of their parents, but
for all intends and purposes their interface is just like the parent
with some additions.
So in other words a child is an instance of all of its parent. If you
remove arguments from the signature of methods this no longer applies
and you have violated this OOP rule.
It should be possible to implement your inheritance in such a way that
this will not bite you, but I do not think its PHP job to police this by
default. I want to bring up again the idea of an optional strict mode
(alternatively we can talk about a lax mode, but I think it makes more
sense to maintain BC and stay lax by default) that does it all according
to academic OOP (check signature of children, disallow on the fly static
properties etc.).
regards,
Lukas
---
## #25085 — Daniel Convissor — 2006-08-01T21:04:58+00:00
URL: https://externals.io/message/24804#25085 · In reply to: #24820
>
> 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.
I agree. For those who want the academic/strict approach, PHP provides
Interfaces.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
---
## #25086 — Marcus Boerger — 2006-08-01T21:41:24+00:00
URL: https://externals.io/message/24804#25086 · In reply to: #24804
Hello Michael,
nobody forces you to use OO if you don't like it but it is as it is. And
we cannot make it ignore its basic rules. It might be that you are lazy and
have code that would end up without problems if changing signatures at will.
However we have a bunch of situations where we cannot allow changes and that
is not only interfaces. It si also about magic functions, all that start
with __, it is about any signature that has default values or type hints or
pass by reference info. So after all where should we draw the line? Any why
just because a few people are to lazy for a few keystrokes? Come on give me
any reason why we should reinvent OOP theory and make it work. Or why we
should change to prototype OOP and make everything damn complex to
understand and break all of BC.
best regards
marcus
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
---
## #25087 — Christian Schneider — 2006-08-01T22:52:27+00:00
URL: https://externals.io/message/24804#25087 · In reply to: #25086
Marcus Boerger wrote:
> nobody forces you to use OO if you don't like it but it is as it is. And
> we cannot make it ignore its basic rules. It might be that you are lazy and
PHP can and PHP did allow changing parameters when overriding functions.
And apart from pseudo-academical reasons nothing convincing was said why
this should be changed. Nobody forces you to change any parameters if
you don't want to ;-)
Why can't we agree that people use classes in different ways (call it
non-OO ways if you want) and restrain from forcing ones views onto
everybody? PHP works well because it of the freedom it gives, not
because of the limitations.
- Chris
---
## #25088 — Edin Kadribasic — 2006-08-01T22:55:19+00:00
URL: https://externals.io/message/24804#25088 · In reply to: #25087
Christian Schneider wrote:
> PHP can and PHP did allow changing parameters when overriding functions.
> And apart from pseudo-academical reasons nothing convincing was said why
> this should be changed. Nobody forces you to change any parameters if
> you don't want to ;-)
>
> Why can't we agree that people use classes in different ways (call it
> non-OO ways if you want) and restrain from forcing ones views onto
> everybody? PHP works well because it of the freedom it gives, not
> because of the limitations.
Amen!
-Edin
---
## #25089 — Pierre — 2006-08-01T23:01:56+00:00
URL: https://externals.io/message/24804#25089 · In reply to: #25087
On Wed, 02 Aug 2006 00:52:27 +0200
cschneid@cschneid.com (Christian Schneider) wrote:
> Why can't we agree that people use classes in different ways (call it
> non-OO ways if you want) and restrain from forcing ones views onto
> everybody? PHP works well because it of the freedom it gives, not
> because of the limitations.
Because there is people who does not want to know the PHP way. They
want their {put your fashion OO language here} way in PHP. Strictness
was never a goal in php.
But it looks like the opinion of the current php users do not matter,
only the ones coming from {put your fashion OO language here}. It seems
that they have hard time to justify the usage of {put your fashion OO
language here}, time to bork PHP.
-- Pierre
---
## #25090 — Rasmus Lerdorf — 2006-08-01T23:11:05+00:00
URL: https://externals.io/message/24804#25090 · In reply to: #25089
Pierre wrote:
> On Wed, 02 Aug 2006 00:52:27 +0200
> cschneid@cschneid.com (Christian Schneider) wrote:
>
>
> > […]
>
>
> Because there is people who does not want to know the PHP way. They
> want their {put your fashion OO language here} way in PHP. Strictness
> was never a goal in php.
>
> But it looks like the opinion of the current php users do not matter,
> only the ones coming from {put your fashion OO language here}. It seems
> that they have hard time to justify the usage of {put your fashion OO
> language here}, time to bork PHP.
>
Relax people. There are certain paradigms and expectations people have.
The original PHP design met the expectations and paradigms of a
loosely typed procedural language. Now, some 12 years later we are
trying to meet a new class of expectations. We have kids coming out of
universities today who barely know what procedural programming is. All
they know is OOP and we want to give them something that meets their
expectations. We have to be careful that we don't ignore too many OOP
rules or we would fail to meet these expectations. The PHP way is not
to make everything look like the procedural approach. The PHP way is to
cater to peoples' existing knowledge and build a language that does what
people expect it to. That doesn't mean we shouldn't loosen up some OOP
rules where it makes sense, but it also doesn't mean we should ignore
them completely.
-Rasmus
---
## #25091 — Robert Amos — 2006-08-01T23:12:58+00:00
URL: https://externals.io/message/24804#25091 · In reply to: #25088
Hear hear!
+1
-bok
>
> Christian Schneider wrote:
> > […]
>
> Amen!
>
> -Edin
>
> --
>
>
>
>
--
Xnyo - http://xnyo.odynia.org/
---
## #25093 — Christian Schneider — 2006-08-01T23:21:14+00:00
URL: https://externals.io/message/24804#25093 · In reply to: #25090
Rasmus Lerdorf wrote:
> trying to meet a new class of expectations. We have kids coming out of
> universities today who barely know what procedural programming is. All
> they know is OOP and we want to give them something that meets their
> expectations. We have to be careful that we don't ignore too many OOP
> rules or we would fail to meet these expectations. The PHP way is not
So give them a superset of what they expect (i.e. the status quo of PHP)
and everybody is happy. They can still use `E_NOTICE` for bondage mode
(like having to initialize all variables and stuff).
- Chris
---
## #25098 — Robert Cummings — 2006-08-02T00:32:27+00:00
URL: https://externals.io/message/24804#25098 · In reply to: #25086
> Hello Michael,
>
> nobody forces you to use OO if you don't like it but it is as it is. And
It is as it is, but not as it was. PHP4 allowed signature mismatching.
> we cannot make it ignore its basic rules. It might be that you are lazy and
> have code that would end up without problems if changing signatures at will.
> However we have a bunch of situations where we cannot allow changes and that
> is not only interfaces. It si also about magic functions, all that start
> with __, it is about any signature that has default values or type hints or
> pass by reference info.
Magic... hmmmm... so PHP is moving to more "magic"?
> So after all where should we draw the line? Any why
> just because a few people are to lazy for a few keystrokes? Come on give me
> any reason why we should reinvent OOP theory and make it work. Or why we
> should change to prototype OOP and make everything damn complex to
> understand and break all of BC.
To make a better language. Following all the sheep out there just makes
for more fodder. Just because it's in the books, doesn't make it the
best way. Innovation doesn't come by following the pack it almost always
comes from changing the game.
Cheers,
Rob.
--
.---------------------------------------------.
| Worlds of Carnage - http://www.wocmud.org |
:---------------------------------------------:
| Come visit a world of myth and legend where |
| fantastical creatures come to life and the |
| stuff of nightmares grasp for your soul. |
`---------------------------------------------'
---
## #25097 — Marcus Boerger — 2006-08-02T00:42:10+00:00
URL: https://externals.io/message/24804#25097 · In reply to: #25098
Hello Robert,
Wednesday, August 2, 2006, 2:32:27 AM, you wrote:
> To make a better language. Following all the sheep out there just makes
> for more fodder. Just because it's in the books, doesn't make it the
> best way. Innovation doesn't come by following the pack it almost always
> comes from changing the game.
This is a ridiculous accusation of my person directly - but thanks. We
chose a damn good set available yet working. And i invented for example
iterators in php, sorry it is only that. But it is far most the best
iterator implementation any language out there has. And i am not paid
for anything (like most of us) so sorry we cannot do it better.
And this time i mean it like i wrote it.
Instead of argumenting like this you guys should start helping us.
Best regards,
Marcus
---
Next page: https://externals.io/message/24804.md?page=2