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-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
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
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. |
`------------------------------------------------------------'
[ ] (+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
[ ] (+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 =)
[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
[] (+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
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
[ ] (+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
-----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 ... butI 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
At 11:10 22/09/2006, Derick Rethans 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 ... butI 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
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:
[ ] (+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 ... butI 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_STRICTand nothing more (also in future versions). That would get my
vote.Zeev
In this case, wouldn't
E_NOTICEmake more sense?E_STRICTkind 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!"
Ron Korving wrote:
In this case, wouldn't
E_NOTICEmake more sense?E_STRICTkind 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
In this case, wouldn't
E_NOTICEmake more sense?E_STRICTkind 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
Derick Rethans wrote:
In this case, wouldn't
E_NOTICEmake more sense?E_STRICTkind of indicates
that certain behaviour is deprecated, right?Not really,
E_STRICTis 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
At 11:10 22/09/2006, Derick Rethans 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 ... butI 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_STRICTand
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
[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_STRICTand nothing more (also in future versions). That would get
my vote.
+1
Split
E_STRICTandE_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
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 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 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
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
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
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:
3, 2 [+1] (remove) Mike, Pierre, Edin (Robert Cummings, Bertrand Gugger)
1, 1 [+0] (nonfatal) Zeev (Richard Lynch)
3, 0 [-1] (leave) Sebastian, Ilia, DerickBTW I think even if Marcus has not voted yet he is sure to be in the
leave as in CVS camp :)regards,
Lukas
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.
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, DerickBTW I think even if Marcus has not voted yet he is sure to be in the
leave as in CVS camp :)regards,
Lukas
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.
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.
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, DerickBTW I think even if Marcus has not voted yet he is sure to be in the
leave as in CVS camp :)regards,
Lukas
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.
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 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_NOTICEwould 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
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
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"?
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 :)
On the same note you can use C and ignore all rules, coding using
only void pointers and relying purely on gotos for flow control. :-)
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 globalWhat do you mean by "creating dynamically and accessing statically"?
Bah never mind, confusing properties with methods, my mistake.
Ilia Alshanetsky
On the same note you can use C and ignore all rules, coding using only
void pointers and relying purely on gotos for flow control. :-)
Sure, and PHP is much closer to "C" (I intentionally use quotes because
it's not matter of language but rather concept, but since you named it,
I will keep this name) than to "Java" in this regard, it allows to do
things that are more powerful - at cost of giving you the opportunity to
shoot yourself in the foot. There are people who think PHP should be
more "C" - like, have gotos, etc. - and there are people who think PHP
should be more "Java" - like have strict signature enforcement or, God
forbid, exception declarations. I personally think PHP is quite good the
way it is. :)
On the other note, C and Java are static compiled languages, and PHP is
dynamic language, which makes doing some things in PHP much easier than
in C or Java. For example, functions with flexible signatures. So I
think we should use it and not only try to restrict it.
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_NOTICEwould 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
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_NOTICEwould 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 aE_NOTICEand 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
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, DerickThere 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