# [VOTE] (was: Parameter checking in 5.2)
- Thread: https://externals.io/message/25785
- Original archive: https://news-web.php.net/php.internals/25785
- Started by Michael Wallner on 2006-09-21T15:02:47+00:00
- Messages: 36
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/25785.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #25785 — Michael Wallner — 2006-09-21T15:02:47+00:00
URL: https://externals.io/message/25785#25785
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.
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'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
---
## #25786 — Pierre — 2006-09-21T15:15:56+00:00
URL: https://externals.io/message/25785#25786 · In reply to: #25785
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
---
## #25789 — Robert Cummings — 2006-09-21T17:15:15+00:00
URL: https://externals.io/message/25785#25789 · In reply to: #25786
> On Thu, 21 Sep 2006 17:02:47 +0200
> mike@php.net (Michael Wallner) wrote:
>
>
> > […]
>
[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. |
`------------------------------------------------------------'
---
## #25791 — Brian Moon — 2006-09-21T19:55:33+00:00
URL: https://externals.io/message/25785#25791 · In reply to: #25785
[ ] (+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 =)
---
## #25792 — Edin Kadribasic — 2006-09-21T21:07:17+00:00
URL: https://externals.io/message/25785#25792 · In reply to: #25791
[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
---
## #25793 — Sebastian Bergmann — 2006-09-21T22:33:52+00:00
URL: https://externals.io/message/25785#25793 · In reply to: #25786
[ ] (+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
---
## #25794 — Ilia Alshanetsky — 2006-09-21T23:48:15+00:00
URL: https://externals.io/message/25785#25794 · In reply to: #25785
[] (+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
---
## #25795 — Kevin Waterson — 2006-09-22T02:21:32+00:00
URL: https://externals.io/message/25785#25795 · In reply to: #25794
This one time, at band camp, Ilia Alshanetsky 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
---
## #25798 — Derick Rethans — 2006-09-22T08:10:19+00:00
URL: https://externals.io/message/25785#25798 · In reply to: #25785
> [ ] (+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
---
## #25799 — Jasper Bryant-Greene — 2006-09-22T08:16:46+00:00
URL: https://externals.io/message/25785#25799 · In reply to: #25798
-----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
---
## #25801 — bertrand Gugger — 2006-09-22T12:35:32+00:00
URL: https://externals.io/message/25785#25801 · In reply to: #25785
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
---
## #25803 — bertrand Gugger — 2006-09-22T12:40:58+00:00
URL: https://externals.io/message/25785#25803 · In reply to: #25801
bertrand Gugger wrote:
> Michael Wallner wrote:
> > […]
>
> 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
---
## #25807 — Zeev Suraski — 2006-09-24T10:49:27+00:00
URL: https://externals.io/message/25785#25807 · In reply to: #25798
At 11:10 22/09/2006, 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).
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
---
## #25808 — Ron Korving — 2006-09-24T15:04:32+00:00
URL: https://externals.io/message/25785#25808 · In reply to: #25807
In this case, wouldn't `E_NOTICE` make more sense? `E_STRICT` kind of indicates
that certain behaviour is deprecated, right?
- Ron
"Zeev Suraski" wrote in message
news:7.0.1.0.2.20060924133501.05254570@zend.com...
> At 11:10 22/09/2006, Derick Rethans wrote:
> > […]
>
> 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
---
## #25813 — Richard Quadling — 2006-09-25T07:49:12+00:00
URL: https://externals.io/message/25785#25813 · In reply to: #25808
> 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&r=213474731
"Standing on the shoulders of some very clever giants!"
---
## #25814 — Sebastian Bergmann — 2006-09-25T08:08:01+00:00
URL: https://externals.io/message/25785#25814 · In reply to: #25808
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
---
## #25823 — Derick Rethans — 2006-09-25T17:28:53+00:00
URL: https://externals.io/message/25785#25823 · In reply to: #25807
> At 11:10 22/09/2006, Derick Rethans wrote:
> > […]
>
> 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
---
## #25824 — Derick Rethans — 2006-09-25T17:29:48+00:00
URL: https://externals.io/message/25785#25824 · In reply to: #25808
> 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
---
## #25832 — Lukas Kahwe Smith — 2006-09-26T07:58:54+00:00
URL: https://externals.io/message/25785#25832 · In reply to: #25824
Derick Rethans wrote:
>
>
> > […]
>
> 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
---
## #25863 — Richard Lynch — 2006-09-28T17:05:49+00:00
URL: https://externals.io/message/25785#25863 · In reply to: #25807
[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
---
## #25948 — Michael Wallner — 2006-10-05T13:04:27+00:00
URL: https://externals.io/message/25785#25948 · In reply to: #25785
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
---
## #25950 — Lukas Kahwe Smith — 2006-10-05T15:39:05+00:00
URL: https://externals.io/message/25785#25950 · In reply to: #25948
Michael Wallner wrote:
> 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
+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
---
## #25951 — Lukas Kahwe Smith — 2006-10-05T16:16:07+00:00
URL: https://externals.io/message/25785#25951 · In reply to: #25948
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
---
## #25961 — Wez Furlong — 2006-10-06T14:28:19+00:00
URL: https://externals.io/message/25785#25961 · In reply to: #25951
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.
> Michael Wallner wrote:
>
> > […]
>
> BTW I think even if Marcus has not voted yet he is sure to be in the
> leave as in CVS camp :)
>
> regards,
> Lukas
---
## #25962 — Edin Kadribasic — 2006-10-06T15:08:56+00:00
URL: https://externals.io/message/25785#25962 · In reply to: #25961
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:
> 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.
>
>
> > […]
---
Next page: https://externals.io/message/25785.md?page=2