Everything

php

Home » Project » Newsgroups » php.internals » [VOTE] (was: Parameter checking in 5.2) »

[VOTE] (was: Parameter checking in 5.2)

php.internals

Michael Wallner

19 years ago

Marcus Boerger wrote:

> Hello Christian,
>
>   the short form is, use interfaces. And the long form is read the upgrade
>   file and find out to use interfaces :-)

Sorry for nagging again, but his issue still concerns me a lot.

The thing is that currently we have inheritance rules that feel
a lot like interfaces (see: "rethink OO inheritance strictness").

I'm having very strong feelings against the current behavior and,
if I remember correctly, I'm not alone.

<quote message-id="EB.71.29121.B6690C44@pb1.pair.com">
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.
</quote>


I'd therefore like to conduct a serious vote on this issue.

[X] (+1) please remove that redundant strictness again
[ ] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?



Regards,

--
Michael

Pierre Joye

19 years ago

On Thu, 21 Sep 2006 17:02:47 +0200
mike@php.net (Michael Wallner) wrote:

> I'd therefore like to conduct a serious vote on this issue.

[X] (+1) please remove that redundant strictness again
[ ] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?

-- Pierre

Robert Cummings

19 years ago

On Thu, 2006-09-21 at 17:15 +0200, Pierre wrote:

> On Thu, 21 Sep 2006 17:02:47 +0200
> mike@php.net (Michael Wallner) wrote:
>
>
> > I'd therefore like to conduct a serious vote on this issue.
>

[X] (+1) please remove that redundant strictness again
[ ] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?

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

Sebastian Bergmann

19 years ago

[ ] (+1) please remove that redundant strictness again
[X] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Brian Moon

19 years ago

[ ] (+1) please remove that redundant strictness again
[ ] (-1) leave as it is, we need strict OO implementation
[X] ( 0) what the hell are you talking about?

--

Brian Moon
-------------
http://dealnews.com/
Its good to be cheap =)

Edin Kadribasic

19 years ago

[X] (+1) please remove that redundant strictness again
[ ] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?

Edin

Ilia A.

19 years ago

[] (+1) please remove that redundant strictness again
[X] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?

Ilia

Kevin Waterson

19 years ago

This one time, at band camp, Ilia Alshanetsky <ilia@prohost.org> wrote:

>
> [] (+1) please remove that redundant strictness again
> [X] (-1) leave as it is, we need strict OO implementation
> [ ] ( 0) what the hell are you talking about?

0

Derick Rethans

19 years ago

On Thu, 21 Sep 2006, Michael Wallner wrote:

> [ ] (+1) please remove that redundant strictness again
> [X] (-1) leave as it is, we need strict OO implementation
> [ ] ( 0) what the hell are you talking about?

It's not necessarily a *strict* OO implementaiton though, it's one that
is correct. Strictness is where we would disallow setting object
properties on the fly while not declaring that. I would actually like to
see that throwing an e_strict too as that would make debugging easier as
well. however, in the case of signatures you *have* to be strict ... but

I guess we would only see the full implications if you're very well
versed with OO theory (definitely not saying that I am).

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Jasper Bryant-Greene

19 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Derick Rethans wrote:

> It's not necessarily a *strict* OO implementaiton though, it's one that
> is correct. Strictness is where we would disallow setting object
> properties on the fly while not declaring that. I would actually like to
> see that throwing an e_strict too as that would make debugging easier as
> well. however, in the case of signatures you *have* to be strict ... but
>
> I guess we would only see the full implications if you're very well
> versed with OO theory (definitely not saying that I am).

Are we not missing the fact that static methods (at least in PHP) are
effectively bound to the specific class that they are defined on, no
matter which they are called on? f.x. see any of the multitude of posts
to this list regarding PHP's lack of late static binding.

On this note, given that there are no real inheritance rules applying
w.r.t. static methods, does it not make sense to allow different
parameters on subclasses as these are effectively different methods as
opposed to overloading in the strict sense?

- --
Jasper Bryant-Greene
Director
Album Limited

jasper@album.co.nz
+64 21 708 334 / 0800 425 286
http://www.album.co.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFcDBQFFE5vtnqZ4vwo6v1gRCiekAP0cof6jTPdqcizYle2fzSAPDjucrxDMkreY
NgaS4i4hMgEAhvii80Zy6dogEFarPU9teL8zrZcyWZvIa5h+UOfrEZo=
=wcz6
-----END PGP SIGNATURE-----

Zeev Suraski

19 years ago

At 11:10 22/09/2006, Derick Rethans wrote:

>On Thu, 21 Sep 2006, Michael Wallner wrote:
>
> > [ ] (+1) please remove that redundant strictness again
> > [X] (-1) leave as it is, we need strict OO implementation
> > [ ] ( 0) what the hell are you talking about?
>
>It's not necessarily a *strict* OO implementaiton though, it's one that
>is correct. Strictness is where we would disallow setting object
>properties on the fly while not declaring that. I would actually like to
>see that throwing an e_strict too as that would make debugging easier as
>well. however, in the case of signatures you *have* to be strict ... but
>
>I guess we would only see the full implications if you're very well
>versed with OO theory (definitely not saying that I am).

I think it's exactly the same thing as setting object properties on
the fly - both can cause problems with certain OO-based
theories/algorithms.  Whatever we call it (strictness, correctness) -
it's pretty much the same.

I think we need a fourth option in the poll - keep the error as
E_STRICT and nothing more (also in future versions).  That would get my vote.

Zeev

Ron Korving

19 years ago

In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
that certain behaviour is deprecated, right?

- Ron


"Zeev Suraski" <zeev@zend.com> wrote in message
news:7.0.1.0.2.20060924133501.05254570@zend.com...

> At 11:10 22/09/2006, Derick Rethans wrote:
> >On Thu, 21 Sep 2006, Michael Wallner wrote:
> >
> > > [ ] (+1) please remove that redundant strictness again
> > > [X] (-1) leave as it is, we need strict OO implementation
> > > [ ] ( 0) what the hell are you talking about?
> >
> >It's not necessarily a *strict* OO implementaiton though, it's one that
> >is correct. Strictness is where we would disallow setting object
> >properties on the fly while not declaring that. I would actually like to
> >see that throwing an e_strict too as that would make debugging easier as
> >well. however, in the case of signatures you *have* to be strict ... but
> >
> >I guess we would only see the full implications if you're very well
> >versed with OO theory (definitely not saying that I am).
>
> I think it's exactly the same thing as setting object properties on
> the fly - both can cause problems with certain OO-based
> theories/algorithms.  Whatever we call it (strictness, correctness) -
> it's pretty much the same.
>
> I think we need a fourth option in the poll - keep the error as
> E_STRICT and nothing more (also in future versions).  That would get my

vote.

Richard Quadling

19 years ago

On 24/09/06, Ron Korving <r.korving@xit.nl> wrote:

> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
> that certain behaviour is deprecated, right?

I think that's a whole other issue. E_STRICT seems to be used for both
errors in coding style (calling static methods from an instance) and
for deprecated functionality (mktime(0,0,0,0,0,0)).

But there again, some may think that both are just coding style issues.

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

Sebastian Bergmann

19 years ago

Ron Korving wrote:

> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of
> indicates that certain behaviour is deprecated, right?

We are moving in circles. Using E_STRICT for both the use of deprecated
language features and the "unstrict" use of language features is
confusing.

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Derick Rethans

19 years ago

On Sun, 24 Sep 2006, Ron Korving wrote:

> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
> that certain behaviour is deprecated, right?

Not really, E_STRICT is for when you're doing something that you
shouldn't. In my opinion that includes using a deprecated function but
adding a new level "E_DEPRECATED" is fine with me as well.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Lukas Smith

19 years ago

Derick Rethans wrote:

> On Sun, 24 Sep 2006, Ron Korving wrote:
>
>> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
>> that certain behaviour is deprecated, right?
>
> Not really, E_STRICT is for when you're doing something that you
> shouldn't. In my opinion that includes using a deprecated function but
> adding a new level "E_DEPRECATED" is fine with me as well.

I think its really about time we make this split.
In that case I would be ok with making signature changes an E_STRICT.
Otherwise I would rather see them removed.

regards,
Lukas

Derick Rethans

19 years ago

On Sun, 24 Sep 2006, Zeev Suraski wrote:

> At 11:10 22/09/2006, Derick Rethans wrote:
> >On Thu, 21 Sep 2006, Michael Wallner wrote:
> >
> > > [ ] (+1) please remove that redundant strictness again
> > > [X] (-1) leave as it is, we need strict OO implementation
> > > [ ] ( 0) what the hell are you talking about?
> >
> >It's not necessarily a *strict* OO implementaiton though, it's one that
> >is correct. Strictness is where we would disallow setting object
> >properties on the fly while not declaring that. I would actually like to
> >see that throwing an e_strict too as that would make debugging easier as
> >well. however, in the case of signatures you *have* to be strict ... but
> >
> >I guess we would only see the full implications if you're very well
> >versed with OO theory (definitely not saying that I am).
>
> I think it's exactly the same thing as setting object properties on the fly -
> both can cause problems with certain OO-based theories/algorithms.  Whatever
> we call it (strictness, correctness) - it's pretty much the same.
>
> I think we need a fourth option in the poll - keep the error as E_STRICT and
> nothing more (also in future versions).  That would get my vote.

As long as we then implement E_STRICT for all the other times where we
are "breaking" OO design that would work.

regards,
Derick

Richard Lynch

19 years ago

[X] (+1) please remove that redundant strictness again
[ ] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?

> I think we need a fourth option in the poll - keep the error as
> E_STRICT and nothing more (also in future versions).  That would get
> my vote.

+1

> Split E_STRICT and E_DEPRECATED

+1

If nothing else, the man-hours saved in discussion on this list will
pay for the man-hours spent to implement it. :-)

'Course, they're not my man-hours to spend, so...

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

bertrand Gugger

19 years ago

Michael Wallner wrote:

> I'd therefore like to conduct a serious vote on this issue.

If my vote , in name of thousands poor hosted people could count.

[X] (+1) please remove that redundant strictness again
[ ] (-1) leave as it is, we need strict OO implementation
[ ] ( 0) what the hell are you talking about?

Thanks to get that definitively clear.

Regards,

--
toggg

bertrand Gugger

19 years ago

bertrand Gugger wrote:

> Michael Wallner wrote:
>> I'd therefore like to conduct a serious vote on this issue.
>
> If my vote , in name of thousands poor hosted people could count.
>
> [X] (+1) please remove that redundant strictness again
> [ ] (-1) leave as it is, we need strict OO implementation
> [ ] ( 0) what the hell are you talking about?
>
> Thanks to get that definitively clear.
>
> Regards,

Errmmm.... sorry for double message , I naturally dont want to vote 2
times ;)

--
toggg

Michael Wallner

19 years ago

Michael Wallner wrote:

> I'd therefore like to conduct a serious vote on this issue.
>
> [X] (+1) please remove that redundant strictness again
> [ ] (-1) leave as it is, we need strict OO implementation
> [ ] ( 0) what the hell are you talking about?

3, 2  [+1] (remove)    Mike, Pierre, Edin (Robert Cummings, Bertrand Gugger)
1, 1  [+0] (nonfatal)  Zeev (Richard Lynch)
3, 0  [-1] (leave)     Sebastian, Ilia, Derick


There are lots of people still missing.

Regards,

--
Michael

Lukas Smith

19 years ago

Michael Wallner wrote:

> Michael Wallner wrote:
>
>> I'd therefore like to conduct a serious vote on this issue.
>>
>> [X] (+1) please remove that redundant strictness again
>> [ ] (-1) leave as it is, we need strict OO implementation
>> [ ] ( 0) what the hell are you talking about?
>
>
>  3, 2  [+1] (remove)    Mike, Pierre, Edin (Robert Cummings, Bertrand Gugger)
>  1, 1  [+0] (nonfatal)  Zeev (Richard Lynch)
>  3, 0  [-1] (leave)     Sebastian, Ilia, Derick

+1 for remove

unless E_STRICT is split into E_STRICT and E_DEPRECATED in which case I
would like this to become an E_STRICT.

regards,
Lukas

Lukas Smith

19 years ago

Michael Wallner wrote:

>  3, 2  [+1] (remove)    Mike, Pierre, Edin (Robert Cummings, Bertrand Gugger)
>  1, 1  [+0] (nonfatal)  Zeev (Richard Lynch)
>  3, 0  [-1] (leave)     Sebastian, Ilia, Derick

BTW I think even if Marcus has not voted yet he is sure to be in the
leave as in CVS camp :)

regards,
Lukas

Wez Furlong

19 years ago

Just a lame ass late-to-the-show comment... I've been out of touch and
this mini thread gives no indication what the vote is about.

Can we try to use more descriptive subjects going forward, thanks!

--Wez.

On 10/5/06, Lukas Kahwe Smith <lsmith@php.net> wrote:

Edin Kadribasic

19 years ago

The vote is should OO strictness (fatal error on changing function
arguments in derived classes in this case) be removed or kept.

Edin

Wez Furlong wrote:

Wez Furlong

19 years ago

Should be non-fatal.
IMO, we shouldn't even be using up CPU cycles to check this; use a
compiled language for that kind of safety.

--Wez.

On 10/6/06, Edin Kadribasic <edink@emini.dk> wrote:

Stanislav Malyshev

19 years ago

> The vote is should OO strictness (fatal error on changing function
> arguments in derived classes in this case) be removed or kept.

I think fatal error should be definitely removed or the rules be at
least relaxed sufficiently to accomodate for PHP flexibility - e.g., ()
should be allowed to be overriden with ($a, $b, $c), etc. In light of
technical difficulty to implement sufficiently flexible cheks, I would
not mind removing them altogether or demoting them to very low priority
notice.

Edin Kadribasic

19 years ago

Stanislav Malyshev wrote:

>> The vote is should OO strictness (fatal error on changing function
>> arguments in derived classes in this case) be removed or kept.
>
> I think fatal error should be definitely removed or the rules be at
> least relaxed sufficiently to accomodate for PHP flexibility - e.g., ()
> should be allowed to be overriden with ($a, $b, $c), etc. In light of
> technical difficulty to implement sufficiently flexible cheks, I would
> not mind removing them altogether or demoting them to very low priority
> notice.

Yes, it was my opinion as well that E_NOTICE would be the most
appropriate choice here.

Edin

Edin Kadribasic

19 years ago

Edin Kadribasic wrote:

> Stanislav Malyshev wrote:
>>> The vote is should OO strictness (fatal error on changing function
>>> arguments in derived classes in this case) be removed or kept.
>>
>> I think fatal error should be definitely removed or the rules be at
>> least relaxed sufficiently to accomodate for PHP flexibility - e.g.,
>> () should be allowed to be overriden with ($a, $b, $c), etc. In light
>> of technical difficulty to implement sufficiently flexible cheks, I
>> would not mind removing them altogether or demoting them to very low
>> priority notice.
>
> Yes, it was my opinion as well that E_NOTICE would be the most
> appropriate choice here.

Hate to have to reply to myself, but to clarify.

I believe that most OO "strictness" fatal errors should be demoted to
notices.

* Changing function signatures in derived classes
* Accessing non-existing class constant (print myclass::myconst)
* Creating class variables (myclass::$myvar = 1)

The last two exist in non-OO versions and there accessing a non-existing
constant is a E_NOTICE and you don't have to declare variables at all,
so I guess we should not take 180 degree turn in their OO equivalents.

Edin

Ilia A.

19 years ago

On 6-Oct-06, at 11:59 AM, Edin Kadribasic wrote:

> I believe that most OO "strictness" fatal errors should be demoted
> to notices.
>
> * Changing function signatures in derived classes

I be wary of allowing this because in some instances method signature
can drastically impact behavior for example
foo(&$bar) {} vs foo($bar); I'd prefer to don't reduce this to
E_NOTICE. (-1)

> * Accessing non-existing class constant (print myclass::myconst)

+1 on this

> * Creating class variables (myclass::$myvar = 1)

You are talking about creating static class variables (dynamic ones
can already be created without even an E_NOTICE). I think if you need
this done, why not create a property dynamically and then access it
statically? I suppose you are using this is a means of having a
global var, in which case you don't have a class instance to init a
property with, but to me it seems like a misuse of the OO
functionality, -1.


Ilia Alshanetsky

Stanislav Malyshev

19 years ago

> I be wary of allowing this because in some instances method signature
> can drastically impact behavior for example
> foo(&$bar) {} vs foo($bar); I'd prefer to don't reduce this to E_NOTICE.

Yes, it can have runtime impact. So what? There are so many cases where,
for example, not declaring a variable upfront or not assigning a type to
it may change script behavior and even introduce a security hole.
However, PHP is built to allow such things, and I do not think we should
prohibit them - especially if there are a lot of valid uses for them. I
think PHP should have priority on flexibility over strictness, if you
prefer strict language you can always have Java and declare everything
up to the last bit :)

> You are talking about creating static class variables (dynamic ones can
> already be created without even an E_NOTICE). I think if you need this
> done, why not create a property dynamically and then access it
> statically? I suppose you are using this is a means of having a global

What do you mean by "creating dynamically and accessing statically"?

Derick Rethans

19 years ago

On Fri, 6 Oct 2006, Edin Kadribasic wrote:

> Edin Kadribasic wrote:
> > Stanislav Malyshev wrote:
> > > > The vote is should OO strictness (fatal error on changing function
> > > > arguments in derived classes in this case) be removed or kept.
> > >
> > > I think fatal error should be definitely removed or the rules be at least
> > > relaxed sufficiently to accomodate for PHP flexibility - e.g., () should
> > > be allowed to be overriden with ($a, $b, $c), etc. In light of technical
> > > difficulty to implement sufficiently flexible cheks, I would not mind
> > > removing them altogether or demoting them to very low priority notice.
> >
> > Yes, it was my opinion as well that E_NOTICE would be the most appropriate
> > choice here.
>
> Hate to have to reply to myself, but to clarify.
>
> I believe that most OO "strictness" fatal errors should be demoted to notices.

This is why we have E_STRICT, not? :)

regards,
Derick

Lukas Smith

19 years ago

Edin Kadribasic wrote:

> Edin Kadribasic wrote:
>> Stanislav Malyshev wrote:
>>>> The vote is should OO strictness (fatal error on changing function
>>>> arguments in derived classes in this case) be removed or kept.
>>>
>>> I think fatal error should be definitely removed or the rules be at
>>> least relaxed sufficiently to accomodate for PHP flexibility - e.g.,
>>> () should be allowed to be overriden with ($a, $b, $c), etc. In light
>>> of technical difficulty to implement sufficiently flexible cheks, I
>>> would not mind removing them altogether or demoting them to very low
>>> priority notice.
>>
>> Yes, it was my opinion as well that E_NOTICE would be the most
>> appropriate choice here.
>
> Hate to have to reply to myself, but to clarify.
>
> I believe that most OO "strictness" fatal errors should be demoted to
> notices.
>
> * Changing function signatures in derived classes
> * Accessing non-existing class constant (print myclass::myconst)
> * Creating class variables (myclass::$myvar = 1)
>
> The last two exist in non-OO versions and there accessing a non-existing
> constant is a E_NOTICE and you don't have to declare variables at all,
> so I guess we should not take 180 degree turn in their OO equivalents.

So it seems that the question seems to be mainly about if this should be
an E_STRICT or E_NOTICE right?

Here is my current understanding of things:
E_STRICT: "improper" yet workable OO code warnings, especially for
unclean code style that will not be removed but also things that are
planned for deprecation in the next major version
E_NOTICE: "improper" yet workable procedural code warnings?

Would be nice to get this resolved before RC6 ..

regards,
Lukas

Derick Rethans

19 years ago

On Thu, 5 Oct 2006, Michael Wallner wrote:

> Michael Wallner wrote:
>
> > I'd therefore like to conduct a serious vote on this issue.
> >
> > [X] (+1) please remove that redundant strictness again
> > [ ] (-1) leave as it is, we need strict OO implementation
> > [ ] ( 0) what the hell are you talking about?
>
>
>  3, 2  [+1] (remove)    Mike, Pierre, Edin (Robert Cummings, Bertrand Gugger)
>  1, 1  [+0] (nonfatal)  Zeev (Richard Lynch)
>  3, 0  [-1] (leave)     Sebastian, Ilia, Derick
>
>
> There are lots of people still missing.

I would rather see that it stays e_error, but a demotion to e_strict
would work for me as well. But then we should also be able to instate
the e_strict for other strictness issues with the OO model (such as
using an undeclared class variable).

regards,
Derick