RfC: rethink OO inheritance strictness

Lukas Smith

20 years ago

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

Richard Quadling

20 years ago

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();

On 21/07/06, Michael Wallner <mike@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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Lukas Smith

20 years ago

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

Derick Rethans

20 years ago

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.

regards,
Derick

Lukas Smith

20 years ago

Derick Rethans wrote:

> 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

20 years ago

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.

On 21/07/06, Lukas Smith <lsmith@php.net> wrote:

> Derick Rethans wrote:
> > 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
>
> --
> 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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Richard Lynch

20 years ago

On Fri, July 21, 2006 4:32 am, Lukas Smith wrote:

> Derick Rethans wrote:
>> On Fri, 21 Jul 2006, Lukas Smith wrote:
>>
>>> Richard Quadling wrote:

[snip]

>>> Its not about being "right". Acedemically Marcus changes are
>>> correct.

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

Mike Bretz

20 years ago

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.bretz@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

20 years ago

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

Sönke Ruempler

20 years ago

Derick Rethans <mailto:derick@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.

-soenke

Richard Quadling

20 years ago

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!

On 21/07/06, Soenke Ruempler <ruempler@topconcepts.com> wrote:

> Derick Rethans <mailto:derick@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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Sönke Ruempler

20 years ago

Richard Quadling <mailto:rquadling@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

Ron Korving

20 years ago

Isn't that why we have interfaces and abstract functions?
(I realize that that would remove the possibility to define a fallback
function in the parent class though.)

- Ron


""Soenke Ruempler"" <ruempler@topconcepts.com> schreef in bericht
news:EDB0F034E395BF4284D66D1FD59EBFDD668D60@sky.stade.topconcepts.net...

Derick Rethans

20 years ago

On Fri, 21 Jul 2006, Soenke Ruempler wrote:

> Derick Rethans <mailto:derick@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

scuzzy

20 years ago

If a constructor gets overridden, why should it not be the same behaviour
with all methods?

-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: 21 July 2006 10:31
To: Mike Bretz
Cc: internals@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Richard Quadling

20 years ago

Exactly. Consistency.

On 21/07/06, Daine Mamacos <scuzzy@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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Andi Gutmans

20 years ago

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.

Andi

Michael Wallner

20 years ago

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.

If there are no other evidences I cannot understand this design move.

--
Michael

Robert Cummings

20 years ago

On Fri, 2006-07-21 at 17:46, Michael Wallner wrote:

> 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.          |
`------------------------------------------------------------'

Christian Schneider

20 years ago

Andi Gutmans wrote:

> 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.

What about factory methods? It makes sense there too.

I could also imagine a base framework which provides very generic
independent classes which are never directly used. An application only
using specialized instances could well profit from simplifying some of
the parameter lists. Less obvious and sneered at by many people I'm sure
but...

... with my main point being that I'd rather have PHP stay too loose
than getting to strict about what's right and what's wrong.

And as someone already pointed out PHP 5 already provides a tool enforce
an interface: Interfaces and abstract classes.

- Chris

Richard Lynch

20 years ago

On Fri, July 21, 2006 4:30 am, Derick Rethans wrote:

> 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).

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

Lukas Smith

20 years ago

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

Pierre Joye

20 years ago

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

Daniel Convissor

20 years ago

On Fri, Jul 21, 2006 at 12:46:13PM +0200, Pierre wrote:

>
> 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

Jared Williams

20 years ago

> 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

Michael Wallner

20 years ago

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

Marcus Börger

20 years ago

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

Marcus Börger

20 years ago

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

Christian Schneider

20 years ago

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

Edin Kadribasic

20 years ago

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

Robert Amos

20 years ago

Hear hear!

+1

-bok

On 8/2/06, Edin Kadribasic <edink@emini.dk> wrote:

>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Xnyo - http://xnyo.odynia.org/

Pierre Joye

20 years ago

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.

<rant>
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.
</rant>

-- Pierre

Rasmus Lerdorf

20 years ago

Pierre wrote:

> 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.
>
> <rant>
> 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.
> </rant>

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

Christian Schneider

20 years ago

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

Lukas Smith

20 years ago

Rasmus Lerdorf wrote:

> 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.

sure .. and all the old users that have become used to how OOP in PHP
works are to be ignored?

regards,
Lukas

Derick Rethans

20 years ago

On Wed, 2 Aug 2006, Lukas Smith wrote:

> Rasmus Lerdorf wrote:
>
> > 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.
>
> sure .. and all the old users that have become used to how OOP in PHP works
> are to be ignored?

Not really, but it's never too late to learn how something really works.
If you want to cater for everybody that thinks that OO support was there
in PHP 4 you're quite lost already :)

regards,
Derick

Zeev Suraski

20 years ago

I believe the problem is that 10 years ago we introduced what can be
described as 'loose OO programming', and we're replacing it (instead
of augmenting it) with strict OO programming.

Zeev

At 02:11 02/08/2006, Rasmus Lerdorf wrote:

Sönke Ruempler

20 years ago

Zeev Suraski <mailto:zeev@zend.com> wrote on Wednesday, August 02, 2006
2:33 PM:

> I believe the problem is that 10 years ago we introduced what can be
> described as 'loose OO programming', and we're replacing it (instead
> of augmenting it) with strict OO programming.

Yes - and I personally like this features in PHP that let me develop
more strictly.

Proposal:

1. Make this BC breakage in 6.0, let it E_STRICT in 5.2 (so 5.1=>5.2 can
be upgraded harmlessly).
2. Make it E_FATAL in 6.0
3. BUT let derived constructors change parameters
a) as constructors are never called from the parent, but optionally from
a child class, it's completely valid IHMO
b) constructors are usally not used in object aggregation / setters, but
called only _ONCE_ at object creation => the creating code knows the
exact (sub-)class and it's constructor.

PS: An real-life example from those wo prefer the old behavior would be
nice ;-)

-soenke

Jared Williams

20 years ago

> PS: An real-life example from those wo prefer the old
> behavior would be
> nice ;-)
>
> -soenke

Yes, I having a hard time imaging one, other than some quick fix.
I'd much rather have some decent refactoring tools.

Jared

Lukas Smith

20 years ago

Jared Williams wrote:

>
>> PS: An real-life example from those wo prefer the old
>> behavior would be
>> nice ;-)
>>
>> -soenke
>
> Yes, I having a hard time imaging one, other than some quick fix.
> I'd much rather have some decent refactoring tools.

The fact of the matter is you do not need the old behaviour (just like
you do not need to new behaviour either) to wrote code.

"Proper" planning would enable anyone to steer clear of having to
rewrite the signature of a method in such a way that it becomes
incompatible with the parent. However glue script languages are about
rapid prototyping and less about planning. Obviously planning is good
and important, however it requires a lot of effort to do it in a clean
OOP way. Especially since I am quite certain that for a lot of
situations clean OOP (as in maintaining the is instance of relationship
for every method) is not necessary or even relevant.

So here is a real world example. Of course it will probably get a lot of
PEAR sucks anyways flack, but so it goes.

The base PEAR class implements an incredibly flexible raiseError()
method that is overkill for most classes. In proper OOP you have to make
the parent implementation the lowest common denominator and add
flexibility (as in additional parameters) inside children. For whatever
reason this was not done. Changing the signature later on was
effectively not feasible as that would have broken BC. So in PEAR::DB
(as well as MDB and MDB2) this method was overwritten with a simpler
signature.

Of course like I mentioned in a post before, an alternative that will be
proper OOP would have been to add a simpleRaiseError() or whatever
method that simply calls parent::raiseError(). However this meant
cluttering the API with the parent method and this new method. So the
"clean" solution would have resulted in clutter.

In all the years of PEAR::DB etc useage I have not seen a single issue
that resulted over this, or even anyone report and issue over this until
it was disallowed in PHP CVS and someone told me that MDB2 doesnt work
with HEAD.

regards,
Lukas

Edin Kadribasic

20 years ago

Zeev Suraski wrote:

> I believe the problem is that 10 years ago we introduced what can be
> described as 'loose OO programming', and we're replacing it (instead
> of augmenting it) with strict OO programming.

That's exactly the problem. We are giving up the "loose" bit of PHP
instead of simply adding "strictness" for those who desire it.

Edin

Rasmus Lerdorf

20 years ago

Zeev Suraski wrote:

> I believe the problem is that 10 years ago we introduced what can be
> described as 'loose OO programming', and we're replacing it (instead of
> augmenting it) with strict OO programming.

Sure, and I agree that we should find a comfortable middleground, I'd
just like to see a little less criticism of Marcus and some more
civilized discussion.  As far as I am concerned, Marcus' approach of
making the existing OOP design consistent with conventional OOP
principles is an extremely valuable one and something I hope he will
continue doing despite all the crap he takes for it.  By going through
this we see where we diverge and we can make deliberate decisions to
loosen things up where it makes sense.

In this particular case I think it should be possible to mark certain
internal methods as strict and keep userspace methods loose.

-Rasmus

Zeev Suraski

20 years ago

At 20:06 02/08/2006, Rasmus Lerdorf wrote:

>Zeev Suraski wrote:
>>I believe the problem is that 10 years ago we introduced what can
>>be described as 'loose OO programming', and we're replacing it
>>(instead of augmenting it) with strict OO programming.
>
>Sure, and I agree that we should find a comfortable middleground,
>I'd just like to see a little less criticism of Marcus and some more
>civilized discussion.  As far as I am concerned, Marcus' approach of
>making the existing OOP design consistent with conventional OOP
>principles is an extremely valuable one and something I hope he will
>continue doing despite all the crap he takes for it.  By going
>through this we see where we diverge and we can make deliberate
>decisions to loosen things up where it makes sense.

Agreed - I definitely value Marcus' great contributions to PHP.  He
does need to be balanced every one in a while :)

>In this particular case I think it should be possible to mark
>certain internal methods as strict and keep userspace methods loose.

Great, so we agree.

Zeev

Pierre Joye

20 years ago

Hi,

On 8/2/06, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> Zeev Suraski wrote:
> > I believe the problem is that 10 years ago we introduced what can be
> > described as 'loose OO programming', and we're replacing it (instead of
> > augmenting it) with strict OO programming.
>
> Sure, and I agree that we should find a comfortable middleground, I'd
> just like to see a little less criticism of Marcus and some more
> civilized discussion.  As far as I am concerned, Marcus' approach of
> making the existing OOP design consistent with conventional OOP
> principles is an extremely valuable one and something I hope he will
> continue doing despite all the crap he takes for it.

In this particular case, nobody says anything against Marcus or his
work but about this change and then about the general direction is
taking regarding strict OO.

We can disagree with him (or anyone else) without being told to stop
to attack him. We never did not, we only disagreed, is it still
possible to disagree?

I think this is the purpose of this list to discuss things, especially
when we disagree on a direction. It is a bit stupid to say that as
there is nothing to discuss if we all agree...

> In this particular case I think it should be possible to mark certain
> internal methods as strict and keep userspace methods loose.

I agree and this is what many people asked.

Cheers,
--Pierre

Lukas Smith

20 years ago

Rasmus Lerdorf wrote:

> Sure, and I agree that we should find a comfortable middleground, I'd
> just like to see a little less criticism of Marcus and some more
> civilized discussion.  As far as I am concerned, Marcus' approach of

Nobody has criticized Marcus work. I have not heard anyone claim that
the additions are not useful. There was just questions if we should not
preserve the old way and what should be the default.

The only thing I criticize Marcus for is to call everybody stupid that
thinks the old way had its uses. But that is unrelated to his awesome
work on PHP OOP.

regards,
Lukas

Derick Rethans

20 years ago

On Wed, 2 Aug 2006, Rasmus Lerdorf wrote:

> Zeev Suraski wrote:
> > I believe the problem is that 10 years ago we introduced what can be
> > described as 'loose OO programming', and we're replacing it (instead of
> > augmenting it) with strict OO programming.
>
> Sure, and I agree that we should find a comfortable middleground, I'd just
> like to see a little less criticism of Marcus and some more civilized
> discussion.  As far as I am concerned, Marcus' approach of making the existing
> OOP design consistent with conventional OOP principles is an extremely
> valuable one and something I hope he will continue doing despite all the crap
> he takes for it.  By going through this we see where we diverge and we can
> make deliberate decisions to loosen things up where it makes sense.
>
> In this particular case I think it should be possible to mark certain internal
> methods as strict and keep userspace methods loose.

But I would like to see atleast an e_strict warning of signatures are
violated to give atleast the options to be strict and get warnings for
it. I am pretty sure Edin doesn't give a **** about e_strict warnings...
so that will work fine. I think that Zeev suggested something like this.

Derick

Pierre Joye

20 years ago

Hello,

On 8/3/06, Derick Rethans <derick@php.net> wrote:

> > In this particular case I think it should be possible to mark certain internal
> > methods as strict and keep userspace methods loose.
>
> But I would like to see atleast an e_strict warning of signatures are
> violated to give atleast the options to be strict and get warnings for
> it. I am pretty sure Edin doesn't give a **** about e_strict warnings...
> so that will work fine. I think that Zeev suggested something like this.

For what I understand (and agree), he meant the other way 'round.
Users who like strictness will have to use an extra keyword in the
declaration. Users who don't care will not have to change anything in
their (working) code.

--Pierre

Derick Rethans

20 years ago

On Thu, 3 Aug 2006, Pierre wrote:

> Hello,
>
> On 8/3/06, Derick Rethans <derick@php.net> wrote:
>
> > > In this particular case I think it should be possible to mark certain
> > > internal
> > > methods as strict and keep userspace methods loose.
> >
> > But I would like to see atleast an e_strict warning of signatures are
> > violated to give atleast the options to be strict and get warnings for
> > it. I am pretty sure Edin doesn't give a **** about e_strict warnings...
> > so that will work fine. I think that Zeev suggested something like this.
>
> For what I understand (and agree), he meant the other way 'round.
> Users who like strictness will have to use an extra keyword in the
> declaration. Users who don't care will not have to change anything in
> their (working) code.

No, he said that with that strict keyword it would E_ERROR out, but
without it it would simply throw an E_STRICT.

Derick

Zeev Suraski

20 years ago

At 10:40 03/08/2006, Pierre wrote:

>Hello,
>
>On 8/3/06, Derick Rethans <derick@php.net> wrote:
>
>> > In this particular case I think it should be possible to mark
>> certain internal
>> > methods as strict and keep userspace methods loose.
>>
>>But I would like to see atleast an e_strict warning of signatures are
>>violated to give atleast the options to be strict and get warnings for
>>it. I am pretty sure Edin doesn't give a **** about e_strict warnings...
>>so that will work fine. I think that Zeev suggested something like this.
>
>For what I understand (and agree), he meant the other way 'round.
>Users who like strictness will have to use an extra keyword in the
>declaration. Users who don't care will not have to change anything in
>their (working) code.

Actually no, what Derick said is what I meant.

I think emitting an E_STRICT notice on violation of a signature is a
very reasonable compromise between the loose and strict worlds.  It's
not scientifically proven, but I very much believe that there's very
strong mapping between those who care about these signatures and
those who have E_STRICT enabled.   I don't see why we need to add any
new modifiers, loose or strict.

Zeev

Rasmus Lerdorf

20 years ago

Pierre wrote:

> Hello,
>
> On 8/3/06, Derick Rethans <derick@php.net> wrote:
>
>> > In this particular case I think it should be possible to mark
>> certain internal
>> > methods as strict and keep userspace methods loose.
>>
>> But I would like to see atleast an e_strict warning of signatures are
>> violated to give atleast the options to be strict and get warnings for
>> it. I am pretty sure Edin doesn't give a **** about e_strict warnings...
>> so that will work fine. I think that Zeev suggested something like this.
>
> For what I understand (and agree), he meant the other way 'round.
> Users who like strictness will have to use an extra keyword in the
> declaration. Users who don't care will not have to change anything in
> their (working) code.

I'm not all that keen on a new keyword for this.  How about using an
interface to indicate strictness?  Isn't this really what interfaces are
all about?

-Rasmus

Richard Lynch

20 years ago

On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:

> I believe the problem is that 10 years ago we introduced what can be
> described as 'loose OO programming', and we're replacing it (instead
> of augmenting it) with strict OO programming.

And there are people who actually LIKE the 'loose OO programming'
paradigm.

Presumably also some who don't really care, but who have significant
bodies of code utilizing the 'looseness' who will simply refuse to
upgrade to PHP 5 -- thus exacerbating the problem of PHP 4 sticking
around for far longer than some would like.

The suggestion for adding some kind of keyword to keep both camps
happy seems reasonable, though I'm not sure I understood the details
of the suggestion...

To avoid breaking BC, it seems to me that:
E_ERROR is not issued without the extra keyword
E_STRICT, which is new anyway, is issued without the extra keyword

So, it would seem, that the extra keyword should be 'loose' and would
suppress the E_STRICT you would otherwise get.

Example:
class C {
function foo () {
}
}

class D extends C {
loose function foo ($a) {
}
}

class E extends C {
function foo ($a) {
}
}

E issues E_STRICT
D does not issue E_STRICT

At no time in a future release will E issue E_ERROR instead of
E_STRICT -- This construct will remain in E_STRICT purgatory for all
time.

Purists who run under E_STRICT get their icky code flagged.
Pragmatists who don't care can keep their same coding style.
BC is not broken.

Everybody's happy?

This *seems* like a workable solution with not too terrible a price in
development, to this naive reader.

--
Like Music?
http://l-i-e.com/artists.htm

Marcus Börger

20 years ago

Hello Richard,

Wednesday, August 2, 2006, 11:55:45 PM, you wrote:

> On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:
>> I believe the problem is that 10 years ago we introduced what can be
>> described as 'loose OO programming', and we're replacing it (instead
>> of augmenting it) with strict OO programming.

> And there are people who actually LIKE the 'loose OO programming'
> paradigm.

> Presumably also some who don't really care, but who have significant
> bodies of code utilizing the 'looseness' who will simply refuse to
> upgrade to PHP 5 -- thus exacerbating the problem of PHP 4 sticking
> around for far longer than some would like.

There is no problem with 4. It works it has its friends. Why should we
discontinue it like Microsoft would do? Give me any reason. We just do
not add new features.


Best regards,
Marcus

Richard Lynch

20 years ago

On Wed, August 2, 2006 5:06 pm, Marcus Boerger wrote:

> Hello Richard,
>
> Wednesday, August 2, 2006, 11:55:45 PM, you wrote:
>
>> On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:
>>> I believe the problem is that 10 years ago we introduced what can
>>> be
>>> described as 'loose OO programming', and we're replacing it
>>> (instead
>>> of augmenting it) with strict OO programming.
>
>> And there are people who actually LIKE the 'loose OO programming'
>> paradigm.
>
>> Presumably also some who don't really care, but who have significant
>> bodies of code utilizing the 'looseness' who will simply refuse to
>> upgrade to PHP 5 -- thus exacerbating the problem of PHP 4 sticking
>> around for far longer than some would like.
>
> There is no problem with 4. It works it has its friends. Why should we
> discontinue it like Microsoft would do? Give me any reason. We just do
> not add new features.

I like 4 just fine!

There are some very nice features in 5, mind you... SOAP springs to mind.

The fact that active development of new features for 4 is the writing
on the wall that it's not something you want to use for new
applications.

My comment was more directed towards those who bemoan the large shared
webhost vendors who have not moved to PHP 5, rather than educated
developers who maintain legacy codebase in 4.

Anyway, there is still some point in the future where we'll actively
discourage users from continuing to use 4, just as we did with 3 and
with 2.

--
Like Music?
http://l-i-e.com/artists.htm

Zeev Suraski

20 years ago

At 01:06 03/08/2006, Marcus Boerger wrote:

>Hello Richard,
>
>Wednesday, August 2, 2006, 11:55:45 PM, you wrote:
>
> > On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:
> >> I believe the problem is that 10 years ago we introduced what can be
> >> described as 'loose OO programming', and we're replacing it (instead
> >> of augmenting it) with strict OO programming.
>
> > And there are people who actually LIKE the 'loose OO programming'
> > paradigm.
>
> > Presumably also some who don't really care, but who have significant
> > bodies of code utilizing the 'looseness' who will simply refuse to
> > upgrade to PHP 5 -- thus exacerbating the problem of PHP 4 sticking
> > around for far longer than some would like.
>
>There is no problem with 4. It works it has its friends. Why should we
>discontinue it like Microsoft would do? Give me any reason. We just do
>not add new features.

I can think of a bunch, security problems, bugs and
stuck-in-the-past-technology-wise problems.
Why should someone who wants to use more modern technologies like
SimpleXML or ext/soap be forced to change the way he's writing PHP
classes?  Answer - no reason.  Which is why compatibility and
considering how the 'loose people' will be able to use PHP versions
is extremely important.

Zeev

Zeev Suraski

20 years ago

At 00:55 03/08/2006, Richard Lynch wrote:

>On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:
> > I believe the problem is that 10 years ago we introduced what can be
> > described as 'loose OO programming', and we're replacing it (instead
> > of augmenting it) with strict OO programming.
>
>And there are people who actually LIKE the 'loose OO programming'
>paradigm.
>
>Presumably also some who don't really care, but who have significant
>bodies of code utilizing the 'looseness' who will simply refuse to
>upgrade to PHP 5 -- thus exacerbating the problem of PHP 4 sticking
>around for far longer than some would like.
>
>The suggestion for adding some kind of keyword to keep both camps
>happy seems reasonable, though I'm not sure I understood the details
>of the suggestion...
>
>To avoid breaking BC, it seems to me that:
>   E_ERROR is not issued without the extra keyword
>   E_STRICT, which is new anyway, is issued without the extra keyword
>
>So, it would seem, that the extra keyword should be 'loose' and would
>suppress the E_STRICT you would otherwise get.
>
>Example:
>class C {
>   function foo () {
>   }
>}
>
>class D extends C {
>   loose function foo ($a) {
>   }
>}
>
>class E extends C {
>   function foo ($a) {
>   }
>}
>
>E issues E_STRICT
>D does not issue E_STRICT
>
>At no time in a future release will E issue E_ERROR instead of
>E_STRICT -- This construct will remain in E_STRICT purgatory for all
>time.
>
>Purists who run under E_STRICT get their icky code flagged.
>Pragmatists who don't care can keep their same coding style.
>BC is not broken.
>
>Everybody's happy?

No, that means that the 'loose guys' (which just want their stuff to
work) need to start going over their code and modify it.
Like I said, I don't think there's any need to add any new keyword in userland.
Instead - bad overriding will result in an E_STRICT, and it will be
possible to tag internal functions so that it'll result in E_ERROR
(in case it's really really bad that they're incorrectly
overridden).  Pureness aside, it should make everyone happy from a
practical point of view.

Zeev

Derick Rethans

20 years ago

On Wed, 2 Aug 2006, Christian Schneider wrote:

> 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 ;-)

You must have missed the couple of reasons why it *is* a bad idea in
this thread then. Go look for them (Andi and Marcus both gave them).

regards,
Derick

Stefan Walk

20 years ago

For the people who have said "I can not understand why this is a bad thing":

http://en.wikipedia.org/wiki/Liskov_substitution_principle

Regards,
Stefan

Hartmut Holzgraefe

20 years ago

Stefan Walk wrote:

> For the people who have said "I can not understand why this is a bad
> thing":
>
> http://en.wikipedia.org/wiki/Liskov_substitution_principle

so it is a bad thing when aiming for substitutability,
i lack to see an argument yet for substitutability being
a must have in all situations
(just as a normalized data model is not always the right
choice in database design ... it's something to aim for
but if it were enforced this would be BAD THING(tm))

--
Hartmut Holzgraefe, Senior Support Engineer                            .

Hauptsitz: MySQL GmbH, Radlkoferstr. 2, D-81373 München
Geschäftsführer: Hans von Bell, Kaj Arnö - HRB München 162140

Richard Lynch

20 years ago

On Wed, August 2, 2006 4:00 am, Stefan Walk wrote:

> For the people who have said "I can not understand why this is a bad
> thing":
>
> http://en.wikipedia.org/wiki/Liskov_substitution_principle

Unless I'm mis-reading pre/post condition strictures...

Given PHP's cheerfully acceptance of additional arguments to
non-existent parameters:

NOT KOSHER:
class a {function f(){}} class b extends a {function f($a){}}
$a = new a;
$b = new b;
$b->f();

Here, the instance $b of b, a subclass of a, cannot have ->f() called
with 0 args without issuing a E_WARNING.
So it violates the substitutability of the subclass.

This, however, seems KOSHER to me:
class a {function f($a){}} class b extends a {function f(){}}
$a = new a;
$b = new b;
$b->f();

So, strictly-speaking, the reference only requires that subclasses
have "more general" parameters than the superclasses.

All of this seems moot, however, unless we have, or plan to have,
software to prove the correctness of PHP scripts.

Writing such software, to demonstrate that a PHP script is "Provably
Correct" with dynamic typing, seems to me like it would be an
NP-incomplete problem, and a non-starter from the get-go...

It's been a long time since I've done any "Provably Correct" research,
but I don't think that the state of the art has changed that much in
this regard -- A few thousand software developers I know would have
been blogging for months if this had changed.

--
Like Music?
http://l-i-e.com/artists.htm

Robert Cummings

20 years ago

On Tue, 2006-08-01 at 23:41 +0200, Marcus Boerger wrote:

> 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.    |
`---------------------------------------------'

Marcus Börger

20 years ago

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

Robert Cummings

20 years ago

On Wed, 2006-08-02 at 02:42 +0200, Marcus Boerger wrote:

> 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

This was not meant as a personal attack. I'm sorry you took it that way.
It was meant as my perception on the idealogy of following the pack.

> 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.

Agreed. Unfortunately I have no time right now. When I have time, as
I've said to Rasmus before on the general list... I'll make sure and
help. Unfortunately that could be a while since I have two kids and a
wife still in school and I'm the sole breadwinner at the moment.

I love PHP and have since I started using it in 2000. I've been somewhat
active on the boards, and probably should have gotten involved with the
project back when I had free time... hindsight is 20/20.

Anyways just to repeat, I didn't mean my comments to be a personal
attack, I know you work hard, I know everyone involved with PHP work
hard, I'm was just giving opinion in general.

Cheers,
Rob.

Ps. sorry my from address is all over the place. I recently upgrade my
mail client and stuff is messed up... such as the default account.

--
.------------------------------------------------------------.
| 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.          |
`------------------------------------------------------------'

Pierre Joye

20 years ago

On Wed, 2 Aug 2006 02:42:10 +0200
helly@php.net (Marcus Boerger) wrote:

> 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.

It is a discussion where developers and users tell their opinion on a
technical (or theoretical) topic. It is the second time in this thread
that you jumped out of your big horse to say such things. It is
pointless. The fact that you work on the iterators or whatever else
does not make you right, not more than me or Christian.

> Instead of argumenting like this you guys should start helping us.

It is what I do, as much if not more as you do, and I second Robert's
opinion. And I do not say that you are responsible for all PHP's recent
troubles, only that I have the same *opinion* than him on this topic.

-- Pierre

Marcus Börger

20 years ago

Hello Pierre,

if you cannot read stop blaming me. It was Robert and not Christian.
And then read carefully again. You might get the connection. If not i
am all sorry.

marcus

Wednesday, August 2, 2006, 12:41:40 PM, you wrote:

> On Wed, 2 Aug 2006 02:42:10 +0200
> helly@php.net (Marcus Boerger) wrote:

>> 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.

> It is a discussion where developers and users tell their opinion on a
> technical (or theoretical) topic. It is the second time in this thread
> that you jumped out of your big horse to say such things. It is
> pointless. The fact that you work on the iterators or whatever else
> does not make you right, not more than me or Christian.

>> Instead of argumenting like this you guys should start helping us.

> It is what I do, as much if not more as you do, and I second Robert's
> opinion. And I do not say that you are responsible for all PHP's recent
> troubles, only that I have the same *opinion* than him on this topic.

> -- Pierre

Best regards,
Marcus

Pierre Joye

20 years ago

On 8/2/06, Marcus Boerger <helly@php.net> wrote:

> Hello Pierre,
>
>   if you cannot read stop blaming me.

Nobody blamed you.

> It was Robert and not Christian.  And then read carefully again. You might get
> the connection. If not i am all sorry.

There is no relation between our current disagreement (and in a
general manner, between our different views of what should be PHP) and
your work. Try to make the difference, it should make everything
easier.

--Pierre

Derick Rethans

20 years ago

On Tue, 1 Aug 2006, Robert Cummings wrote:

> On Tue, 2006-08-01 at 23:41 +0200, Marcus Boerger wrote:
> > 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.

Yeah, but PHP 4 didn't have OO support, so that argument doesn't count.

regards,
Derick

Lukas Smith

20 years ago

Derick Rethans wrote:

> On Tue, 1 Aug 2006, Robert Cummings wrote:
>
>> On Tue, 2006-08-01 at 23:41 +0200, Marcus Boerger wrote:
>>> 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.
>
> Yeah, but PHP 4 didn't have OO support, so that argument doesn't count.

Whatever .. then call it PHPOO .. either way it is obvious that:
1) proper OO code requires more planning. in the current context it
means that you need to put more time into planning your inheritance
structure. making sure that your parent has actually the most simple
signature you will ever need, and expand on this interface in your children.

2) it is simply often not feasible to change the parent inside a large
code base if you decide that its necessary to change the signature.
obviously this breaks the "is instance of" relation for that method. a
possible solution is to simply add a new method in this case. this is a
way out of the dilemma. however it means that you may end up adding
several methods and leaving in several that are likely to never be used.
and more importantly i have seen plenty of OO code that does not require
the "is instance of" relation for any or atleast all methods.

remember PHP is a glue language .. to me this means it should stress
freedom above all. that being said i think it is also a good idea that
PHP is becoming a first grade language in its own right. however
dropping its ability to function as a rapid glue language is a bad idea.
and i personally have made good use of the PHP4 OO model and so just
telling me to go back to procedural is not acceptable.

again i feel that people who want to use PHP as a "proper" OO language
will definately benefit from a strict mode if they are willing to put in
the extra planning. however alienating the userbase for this by making
it impossible to keep the old low planning OO style would be a bad idea.

regards,
Lukas

regards,
Lukas

Ron Korving

20 years ago

If I might make a suggestion...

I see two camps here, one in favor of freedom and others in favor of
reliability in inheritance. I think both make good points. Maybe there is a
way out that can please both and even another group of people.

Maybe, for PHP6, it's an idea to start supporting function overloading. I
know this is problematic because of func_get_args(), but I think there's a
way around that problem. I think it's extremely rare or perhaps never that
people would want to combine function overloading and func_get_args().

So, my suggestion is this: why not support function overloading in PHP6,
where functions can be implemented with different signatures. If a function
is called with a number of arguments that does not match any of the
implemented functions, an error is triggered if there is more than 1
implementation of a function, otherwise that 1 function is called.

You can use different function signatures compared to parent classes, but
abstract functions with a set amount of parameters really do need to be
implemented with those parameters.

Hopefully with this situation everyone can be happy (including a group of
people who would love to see function overloading).

Just a thought.

- Ron


"Lukas Smith" <lsmith@php.net> schreef in bericht
news:E9.41.45114.FFB50D44@pb1.pair.com...

Hartmut Holzgraefe

20 years ago

Ron Korving wrote:

> So, my suggestion is this: why not support function overloading in PHP6,

because in PHPs dynamicly typed world this would require runtime
checks *on every single function call* as things can't be resolved
at compile time?

--
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Richard Quadling

20 years ago

This is where PHP's strengths can be seen as a weakness. If parameter
overloading is wanted then it would be easier if PHP was not a loosely
typed language.

But, just for arguments sake, if E_STRICT was active _and_ type
hinting was available for ALL types, then at compile time, you COULD
build the appropriate parameter signature.

And parameter overloading could work.

No E_STRICT and you don't have it.

E_STRICT may be the name to use as this would be breaking the
"contract" between parent and child and the issue of "instance of"
does appear again.

I would LOVE type hinting, just so that auto documentors can say that
this function requires a datetime as an integer and not a datetime as
a string (sort of thing).


On 02/08/06, Hartmut Holzgraefe <hartmut@mysql.com> wrote:

> Ron Korving wrote:
>
> > So, my suggestion is this: why not support function overloading in PHP6,
>
> because in PHPs dynamicly typed world this would require runtime
> checks *on every single function call* as things can't be resolved
> at compile time?
>
> --
> Hartmut Holzgraefe, Senior Support Engineer                            .
> MySQL AB, www.mysql.com
>
> --
> 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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Hartmut Holzgraefe

20 years ago

Richard Quadling wrote:

> This is where PHP's strengths can be seen as a weakness. If parameter
> overloading is wanted then it would be easier if PHP was not a loosely
> typed language.

it wouldn't bee PHP then anymore, neither from the user experience
nor from its internal implementation. This would require an almost
100% rewrite ...

--
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Richard Quadling

20 years ago

That was done before, so it could be done again. In principle, there
is nothing wrong with refactoring or even rewriting, except time and
effort.

We have OOP developers wanting OOP things that they've seen working
fine in other languages and non-OOP'ers wondering why!

As this is a discussion forum, all things SHOULD be considered!

On 02/08/06, Hartmut Holzgraefe <hartmut@mysql.com> wrote:

>This would require an almost 100% rewrite ...

--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Richard Lynch

20 years ago

On Wed, August 2, 2006 5:30 am, Hartmut Holzgraefe wrote:

> Ron Korving wrote:
>
>> So, my suggestion is this: why not support function overloading in
>> PHP6,
>
> because in PHPs dynamicly typed world this would require runtime
> checks *on every single function call* as things can't be resolved
> at compile time?

Yes and no.

The Lisp guys have dealt with this issue for DECADES and have several
slick work-arounds to optimize this checking.

First, you *CAN* check the number of args at compile time, and reduce
your search-space considerably that way.

Lisp also caches the inheritence order for which method to call "next"
for multiple-inhertence classes.

I believe that method signatures could also be cached on class
definitions in such a way that it would NOT drastically affect
performance to check which method to run.

So while the checks would need to be done at run-time, the information
to lookup which method to call could be reduced to a minimal lookup
routine of O(1) or O(log N) or somewhere in that range, where N is the
number of ancestors.

There is no need to rule out using func_get_args() -- Once the method
whose signature matches has been called, there's no reason why
func_get_args() could not be utilized to process the args that
"remain" for a matching signature.  I.e., a method signature would
"match" if the parameters list matches the corresponding arguments --
and any additional arguments need not be considered a failure to
"match"

This would probably best be done in PHP 7 rather than 6, I should
think -- but it's a VERY good reason to not paint ourselves into a
corner with OOP strictness today which will have to be violated with a
BC-breaking change somewhere down the road when polymorphism is
supported.

If we want to condemn PHP to *never* support polymorphism, then
enforcing the parameter lists to match seems less problematic -- But
if there's a gleam in the eye for polymorphism "some day" this
restriction seems a bit short-sighted to me.

--
Like Music?
http://l-i-e.com/artists.htm

Derick Rethans

20 years ago

On Wed, 2 Aug 2006, Lukas Smith wrote:

> again i feel that people who want to use PHP as a "proper" OO language will
> definately benefit from a strict mode if they are willing to put in the extra
> planning. however alienating the userbase for this by making it impossible to
> keep the old low planning OO style would be a bad idea.

So then the only option is to introduce a
"i-dont-want-to-care-about-oo-in-my-classes-mode" for the people who
simply don't care.

Derick

Lukas Smith

20 years ago

Derick Rethans wrote:

> On Wed, 2 Aug 2006, Lukas Smith wrote:
>
>> again i feel that people who want to use PHP as a "proper" OO language will
>> definately benefit from a strict mode if they are willing to put in the extra
>> planning. however alienating the userbase for this by making it impossible to
>> keep the old low planning OO style would be a bad idea.
>
> So then the only option is to introduce a
> "i-dont-want-to-care-about-oo-in-my-classes-mode" for the people who
> simply don't care.

yes .. it should be possible to set this on a per class basis. and
children should be able to change the mode. classes in lax mode might
also return false unless the classes match exactly.

regards,
Lukas

Christian Schneider

20 years ago

Lukas Smith wrote:

>> So then the only option is to introduce a
>> "i-dont-want-to-care-about-oo-in-my-classes-mode" for the people who
>> simply don't care.
>
> yes .. it should be possible to set this on a per class basis. and
> children should be able to change the mode. classes in lax mode might
> also return false unless the classes match exactly.

Overkill. PHP already has a strict mode (E_NOTICE) so there's no need to
introduce yet another level of complexity.

- Chris

Zeev Suraski

20 years ago

At 12:44 02/08/2006, Lukas Smith wrote:

>Derick Rethans wrote:
>
>>On Wed, 2 Aug 2006, Lukas Smith wrote:
>>
>>>again i feel that people who want to use PHP as a "proper" OO language will
>>>definately benefit from a strict mode if they are willing to put
>>>in the extra
>>>planning. however alienating the userbase for this by making it
>>>impossible to
>>>keep the old low planning OO style would be a bad idea.
>>So then the only option is to introduce a
>>"i-dont-want-to-care-about-oo-in-my-classes-mode" for the people
>>who simply don't care.
>
>yes .. it should be possible to set this on a per class basis. and
>children should be able to change the mode. classes in lax mode
>might also return false unless the classes match exactly.

I actually think this can be on a per method basis, so that methods
where it's strictly required (such as certain magic method as Marcus
said) will be able to set it, without affecting the entire
class.  It's at the method level that the developer knows whether
overriding methods must adhere to the same signature.


My recommendation:
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'
- In case such a strict method is improperly overridden - error out (E_ERROR)
- In case a non-strict method is improperly overridden - emit E_STRICT
- Consider adding userland ability to set entire classes or methods as strict

Most people who use 'strict OO' will have E_STRICT enabled and have
their code E_STRICT clean, so providing userland support for tagging
classes/methods as strict is probably not really necessary.

Zeev

Jochem Maas

20 years ago

Zeev Suraski wrote:

...

>
>
> My recommendation:
> - Add a new flag to methods (at the implementation level) that will
> allow to flag them as 'strict'
> - In case such a strict method is improperly overridden - error out
> (E_ERROR)
> - In case a non-strict method is improperly overridden - emit E_STRICT
> - Consider adding userland ability to set entire classes or methods as
> strict
>
> Most people who use 'strict OO' will have E_STRICT enabled and have
> their code E_STRICT clean, so providing userland support for tagging
> classes/methods as strict is probably not really necessary.

one thing occur to me (from a enduser's POV):
E_STRICT is often used to denote usage that is depreciated and/or 'evil' with
the implication (when it's not explicitly mentioned) that in future one will
no longer be able to rely on the said usage. this makes, by implication,
anything that produces an E_STRICT is 'second class' which I believe is not
the implication that should be made here.

E_STRICT has seemingly been abused regarding it's meaning and it seems to
me that there is a need to differentiate between strictness and depreciation
(E_DEPRECIATED? E_EVIL?). I personally don't want to write/use code that is
depreciated [if I can help it] but mostly I don't give 2 hoots about strictness
(for instance, I'm quite disciplined enough to write matching method signatures
in relevant subclasses when that is needed; without php always forcing it upon me)

kind regards,
Jochem

PS - very nice to see someone come with up with a definite suggestion that does take
into account the voice of the [legion of?] php-nobodies who have concerns/issues
regarding the 'strictness' stuff that's been creeping in lately.

Michael Wallner

20 years ago

Zeev Suraski wrote:

> My recommendation:
> - Add a new flag to methods (at the implementation level) that will allow to flag them as 'strict'
> - In case such a strict method is improperly overridden - error out (E_ERROR)

Zeev, ain't your recommendation already covered by interfaces?

> - In case a non-strict method is improperly overridden - emit E_STRICT
> - Consider adding userland ability to set entire classes or methods as strict

Regards,

--
Michael

Richard Quadling

20 years ago

I suppose it could be argued that if you want parameter overloading,
then don't declare any parameters to the method and use
func_get_args(). This WOULD give the userland code the appearance of
parameter overloading. (I'm sure that this was mentioned). But I
remember that there where "issues" with func_get_args (sorry - not
really sure what they were).

But, with regards to the original topic "rethink OO inheritence
strictness", this DOES seem that PHP is forcing userland code to obey
1 rule rather than allowing the user to extend as they see fit.


On 02/08/06, Zeev Suraski <zeev@zend.com> wrote:

> I actually think this can be on a per method basis, so that methods
> where it's strictly required (such as certain magic method as Marcus
> said) will be able to set it, without affecting the entire
> class.  It's at the method level that the developer knows whether
> overriding methods must adhere to the same signature.
>
>
> My recommendation:
> - Add a new flag to methods (at the implementation level) that will
> allow to flag them as 'strict'
> - In case such a strict method is improperly overridden - error out (E_ERROR)
> - In case a non-strict method is improperly overridden - emit E_STRICT
> - Consider adding userland ability to set entire classes or methods as strict
>
> Most people who use 'strict OO' will have E_STRICT enabled and have
> their code E_STRICT clean, so providing userland support for tagging
> classes/methods as strict is probably not really necessary.
>
> Zeev
>
> --
> 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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Derick Rethans

20 years ago

On Wed, 2 Aug 2006, Zeev Suraski wrote:

> My recommendation:
> - Add a new flag to methods (at the implementation level) that will allow to
> flag them as 'strict'

Have an example of what you mean here?

regards,
Derick

Robert Cummings

20 years ago

On Wed, 2006-08-02 at 16:07 +0200, Derick Rethans wrote:

> On Wed, 2 Aug 2006, Zeev Suraski wrote:
>
> > My recommendation:
> > - Add a new flag to methods (at the implementation level) that will allow to
> > flag them as 'strict'
>
> Have an example of what you mean here?

Maybe something like the following...

<?

class foo
{
function bleh( $p1, $p2 )
{
echo "Bleh: $p1, $p2\n";
}
}

class fee extends foo
{
loose function bleh( $p1 )
{
parent::bleh( $p1, $this->prop );
}
}

?>

I think I like it :D In this case, no E_STRICT would be issued since we
specifically declared it as loose. if no "loose" declaration had been
added then as Zeev suggested an E_STRICT would be issued. If a "strict"
declaration was added then an E_ERROR would be issued. This would
provide backwards compatibility with an E_STRICT hit, and forward
compatibility without the E_STRICT hit so that your code doesn't look
erroneous. I think E_STRICT should enforce PHP rules, not OOP rules, so
in that sense no E_STRICT would be fired since the code follows the
rules of PHP development. Someone correct me if that is not PHPs
intended use of E_STRICT.

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.          |
`------------------------------------------------------------'

Todd Ruth

20 years ago

Hooray!  Thank you, Zeev!  I'd nearly given up hope on ever moving
to a new version of php.  (Actually, I'm still doomed for using $this
in static calls to an unrelated class, but every bit of avoiding
fatal errors helps.)  Our code may not be OO, but it's definitely
php. ;)

Thanks,
Todd

On Wed, 2006-08-02 at 15:43 +0300, Zeev Suraski wrote:

Zeev Suraski

20 years ago

At 10:41 02/08/2006, Derick Rethans wrote:

>On Tue, 1 Aug 2006, Robert Cummings wrote:
>
> > On Tue, 2006-08-01 at 23:41 +0200, Marcus Boerger wrote:
> > > 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.
>
>Yeah, but PHP 4 didn't have OO support, so that argument doesn't count.

It sure as hell did.

Zeev

Derick Rethans

20 years ago

On Wed, 2 Aug 2006, Zeev Suraski wrote:

> At 10:41 02/08/2006, Derick Rethans wrote:
> >
> >Yeah, but PHP 4 didn't have OO support, so that argument doesn't count.
>
> It sure as hell did.

You can hardly call an array with another table with function pointers
OO :)

regards,
Derick

Zeev Suraski

20 years ago

At 15:49 02/08/2006, Derick Rethans wrote:

>On Wed, 2 Aug 2006, Zeev Suraski wrote:
>
> > At 10:41 02/08/2006, Derick Rethans wrote:
> > >
> > >Yeah, but PHP 4 didn't have OO support, so that argument doesn't count.
> >
> > It sure as hell did.
>
>You can hardly call an array with another table with function pointers
>OO :)

Watch me :)  The fact of the matter is that people used this
infrastructure in an object oriented way.  It wasn't exactly
Smalltalk or Java, but many developers used it to implement some of
the more common OO practices (encapsulation, inheritence).  I guess
you could call it 'cooperative OO' (a-la Windows 3.x's cooperative
multitasking).

Anyway, whatever we call it, it's a fact that a lot of people are
using it.  I think it's more than reasonable to assume that if
several people here on the relatively purist internals@ say they'd
want to go on using it, there are many like them in the PHP
userbase.  Finding a compromise that gives both 'camps' a workable
solution makes the most sense here.

Zeev

Michael Wallner

20 years ago

Marcus Boerger wrote:

> 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.

I'm afraid--I'm just really afraid of it.  We'll lose a huge part of
our freedom we've been used to.  This is a big move which will make PHP
rigidly strict.  Marcus, why force the restricting paradigms of OOP
while we don't have the flexible available?  It really seems artificial
and cumbersome to me.  Are there really good reasons to force people
to good practice?  I don't think this has ever been a motto of PHP,
but I guess, if the majority of the leading forces thinks that this
direction is desirable, I can't do anything about it than being
afraid and disappointed.

If people don't understand why I'm so afraid, I probably can't help,
maybe I just cannot explain my doubts good enough.

ps: Using magic functions is like using interfaces in my POV.

Thank you,

--
Michael

Richard Lynch

20 years ago

On Tue, August 1, 2006 4:41 pm, Marcus Boerger wrote:

> it is about any signature that has default values or type
> hints or
> pass by reference info.

Specialized functions, such as constructors, getters/setters, etc,
would seem to me to be a Special Case, since PHP automatically calls
the parent function and has to pass the args on up the inheritence
tree.

But I'm still not getting it in the general case of user-defined methods.

Why would default values or type hints in the signature of a
parent/child interfere with the arglist of a child/parent?

The desire for this flexibility isn't about being "lazy" or trying to
break some basic OOP theory.

Perhaps I'm just so ingrained from 15 years of Lisp hacking that the
idea of forced similarities between method parameters is anathema, but
there have been innumerable times in the past where I had children
with different arglists than their parents for the same method.

I realise that PHP has no polymorphism (today, at least) and I can
sort of see how one might then assume that all child methods would
have the same signature in theory, but, in practice, it seems to me
like an artificial restriction with no underlying reason.

Consider something like this:

class basic_object {
function draw_self (){
}
}

class window extends basic_object {
function draw_self (){
}
}

class themed_window extends window {
function draw_self ($color = 'blue'){
}
}

Is it really that much of stretch of imagination that one might want
this -- particularly with a much larger inheritence tree than this
silly 3-class example?

Where is the harm in this?

--
Like Music?
http://l-i-e.com/artists.htm