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
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 1mike@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 1I 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
I agree with this point. The sub class is a valid entity in its own
right. The methods (and the parameters) it has are part of that class.
If they overwrite a parent class's method, then fine. Instance of
either class would have different parameters for the same named
method.
If the sub class needs to call the parent then it can using parent::method();
Hi (Marcus),
unfortunately I'm not very happy with the direction OO strictness takes
in PHP. I'm sure I'm not alone and many people second this feeling.Precisely, let's have a look at the following:
mike@honeybadger:~/build/php-5.2-debug$ cli -d"error_reporting=8191" -r 'class c{function f(){}} class d extends c{function f($a){}}'
Strict Standards: Declaration of d::f() should be compatible with that of c::f() in Command line code on line 1mike@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 1I really think that this enforcements are no good idea and
I beg you that we leave this "area" to interfaces.Regards,
Michael
--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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
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
Derick Rethans 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
I see it as catch up to OOP. I've never used Java. I've used Delphi though.
I suppose the main issue is that userland sees OOP and expects things
to be similar to other OOPs they've used. They're blinkered as to why
it ISN'T the same! Like discrete setters/getters providing
accesssibilty or being able to promote/demote visibility via
inheritence.
Derick Rethans wrote:
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
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Derick Rethans 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
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 1mike@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 1I 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
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
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 1mike@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 1I 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
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
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
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
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
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
Hear hear!
+1
-bok
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
--
--
Xnyo - http://xnyo.odynia.org/
On Wed, 02 Aug 2006 00:52:27 +0200
cschneid@cschneid.com (Christian Schneider) wrote:
<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.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.
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
Pierre wrote:
On Wed, 02 Aug 2006 00:52:27 +0200
cschneid@cschneid.com (Christian Schneider) wrote:<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.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.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
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
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
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
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:
Pierre wrote:
On Wed, 02 Aug 2006 00:52:27 +0200
cschneid@cschneid.com (Christian Schneider) wrote:<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>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.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
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
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
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
Hi,
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
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
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
Hello,
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
Hello,
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
At 10:40 03/08/2006, Pierre wrote:
Hello,
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
Hello,
On Thu, 03 Aug 2006 10:48:38 +0300
zeev@zend.com (Zeev Suraski) wrote:
Actually no, what Derick said is what I meant.
I think emitting an
E_STRICTnotice 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 haveE_STRICTenabled.
Yes and no. Yes because E_STRICT already contains some OO only warnings
and no because there is many problems catched by E_STRICT that are not
related to OO good/bad practices, but they are still important and
should be fixed.
That's again the same problem, like many other I do develop with the
most verbose method to prevent any kind of technical troubles (now or
later) with my applications. I do not consider this issue as a
technical problem. But having such annoying E_STRICT warnings prevent
me to use it.
I don't see why we need to add any new modifiers, loose or strict.
I don't see why PHP has suddenly to enforce design rules either, but
you know that.
-- Pierre
Hi,
well it seems that the initial vision of E_STRICT to denote future
deprecation is no longer valid. Then again it might have been a
misunderstanding from the beginning as E_DEPRECATED would have been the
more obvious name in that case.
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.
This reminds me again about my question of how E_STRICT warnings are
added and how things are then handled (E_STRICT becomes E_ERROR or the
feature is removed entirely) with the future releases. I think a clear,
written down policy is needed (and as always may be overwritten via
common sense on a case by case basis).
regards,
Lukas
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.
I don't think it is better as it would require somebody (in one of the
teams) to modify their source files.
regards,
Derick
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.I don't think it is better as it would require somebody (in one of the
teams) to modify their source files.
Sorry, I don't buy this argument. It is new, there is no code to
change if someone likes to use it. But anyone who does not want it has
to change his code.
--Pierre
Derick Rethans wrote:
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.I don't think it is better as it would require somebody (in one of the
teams) to modify their source files.
Err? Code that already works, still works if we make the loose mode the
default. Anyone who writes new classes can make use of a new strict flag
however.
regards,
Lukas
Derick Rethans wrote:
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.I don't think it is better as it would require somebody (in one of the
teams) to modify their source files.Err? Code that already works, still works if we make the loose mode the
default. Anyone who writes new classes can make use of a new strict flag
however.
Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, so it is not a good solution.
regards,
Derick
Hello,
Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, so it is not a good solution.
I doubt this is a valid concerns. Our code is actually broken and now.
You want more strictness? Require 5.2+ for your applications but don't
break our apps for such reasons.
--Pierre
Err? Code that already works, still works if we make the loose mode the
default. Anyone who writes new classes can make use of a new strict flag
however.Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, so it is not a good solution.
Currently, if E_STRICT is enabled, you get an E_STRICT non-fatal
notice. Disabling E_STRICT (as you want to NOT be strict with the
code) gives no warning.
So, either userland code is STRICT (in PHP's terms - not
C++/Delphi/Java) and no overloading is allowed and if you try you get
the compile notice OR it is NOT strict and you can overload and get no
notice.
Toggling E_STRICT has no effect at runtime (for this issue) as the
error is raised at compile time.
So, is this problem solved? Very simply, if you want to overload
parameters, don't use E_STRICT.
The issue this brings is toggling E_STRICT on and off at RUNTIME
required? (I suspect that would be a LOT of work).
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
The issue this brings is toggling
E_STRICTon and off at RUNTIME
required? (I suspect that would be a LOT of work).
It's only an issue for the first script that is opened... not for
includes. As the parsing E_STRICT things work fine.... but only after
the file has been executed. In this example the included file will never
throw e_Strict errors for example:
<?php
error_reporting(0);
include 'included.php';
?>
so it's not a real issue.
Derick
The issue this brings is toggling
E_STRICTon and off at RUNTIME
required? (I suspect that would be a LOT of work).It's only an issue for the first script that is opened... not for
includes. As the parsingE_STRICTthings work fine.... but only after
the file has been executed. In this example the included file will never
throw e_Strict errors for example:<?php
error_reporting(0);
include 'included.php';
?>
Aha. So, if I use an __autoloader, I COULD be clever and place my
"loose" classes in 1 directory and my "strict" classes in another. The
autoloader would search for the class and set the error_reporting
level appropriately before including/requiring.
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
The issue this brings is toggling
E_STRICTon and off at RUNTIME
required? (I suspect that would be a LOT of work).It's only an issue for the first script that is opened... not for
includes. As the parsingE_STRICTthings work fine.... but only after
the file has been executed. In this example the included file will never
throw e_Strict errors for example:<?php
error_reporting(0);
include 'included.php';
?>Aha. So, if I use an __autoloader, I COULD be clever and place my
"loose" classes in 1 directory and my "strict" classes in another. The
autoloader would search for the class and set the error_reporting
level appropriately before including/requiring.
Yeah, that would work.
Derick
Derick Rethans wrote:
Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, so it is not a good solution.
The same was true for PPP.
But like you I prefer the E_STRICT version without modifying the
language though. But I'm sharing Lukas' concern about the definition of
E_STRICT: Is it to be changed to E_ERROR at some point? Otherwise
E_NOTICE would be more appropriate IMHO.
Whatever solution is implemented I propose to relax the test to not test
static functions (e.g. useful for factory methods) and to allow adding
default values to functions (the object of the inherited class still
accepts the same parameters as the base class). A patch is attached.
- Chris
Christian Schneider wrote:
But like you I prefer the
E_STRICTversion without modifying the
language though. But I'm sharing Lukas' concern about the definition of
E_STRICT: Is it to be changed toE_ERRORat some point? Otherwise
E_NOTICEwould be more appropriate IMHO.
Not that I am advocating this, but one solution could be splitting
E_STRICT into E_STRICT and E_DEPRECATED for the respective meanings.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Lukas Smith wrote:
Hi,
well it seems that the initial vision of
E_STRICTto denote future
deprecation is no longer valid. Then again it might have been a
misunderstanding from the beginning asE_DEPRECATEDwould have been the
more obvious name in that case.
I did try to point this out but I was probably ignored due to lack of
karma (which is understandable given the volume of the thread).
I don't care much about real strictness issues but I do develop with
E_STRICT on because it tells me about things in my code that are depreciated
and/or will be removed in future versions (which is something I do care about).
so it seems an E_DEPRECIATED might be needed (requiring alot of E_STRICTS to
be changed), or alternatively something like an E_NOTRECOMMENDED?
someone just mentioned the the possibility of having this strictness
(and maybe others?) error be thrown as an E_NOTICE. I personally like this
approach because E_NOTICE does not have the same "this is second class code and
the ability to run it will disappear in the future" connotations as E_STRICT
does.
kind regards,
Jochem
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.This reminds me again about my question of how
E_STRICTwarnings are
added and how things are then handled (E_STRICT becomesE_ERRORor the
feature is removed entirely) with the future releases. I think a clear,
written down policy is needed (and as always may be overwritten via
common sense on a case by case basis).regards,
Lukas
I think this is all going way too far. If one wants a "loose" class, you'll
just have to suppress errors? That just doesn't sound right. It's like
having a feature, but the system telling you "don't use it! it's bad!".
If anything, I think E_NOTICE would be much better than E_STRICT, which only
seems to be an option because the not-loose classes are called "strict"
classes.
Still, I think triggering errors/notices/whatevers just sounds wrong. People
want to code clean with all messages visible, And want to use (or not use)
this loose feature that's being discussed. I would never dream of using a
feature that triggers error messages, and so the feature isn't viable for me
(and a lot of other people).
- Ron
"Jochem Maas" jochem@iamjochem.com schreef in bericht
news:44D1C58F.8060209@iamjochem.com...
Lukas Smith wrote:
Hi,
well it seems that the initial vision of
E_STRICTto denote future
deprecation is no longer valid. Then again it might have been a
misunderstanding from the beginning asE_DEPRECATEDwould have been the
more obvious name in that case.I did try to point this out but I was probably ignored due to lack of
karma (which is understandable given the volume of the thread).I don't care much about real strictness issues but I do develop with
E_STRICTon because it tells me about things in my code that are
depreciated
and/or will be removed in future versions (which is something I do care
about).so it seems an E_DEPRECIATED might be needed (requiring alot of E_STRICTS
to
be changed), or alternatively something like an E_NOTRECOMMENDED?someone just mentioned the the possibility of having this strictness
(and maybe others?) error be thrown as an E_NOTICE. I personally like this
approach becauseE_NOTICEdoes not have the same "this is second class
code and
the ability to run it will disappear in the future" connotations as
E_STRICT
does.kind regards,
JochemI still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.This reminds me again about my question of how
E_STRICTwarnings are
added and how things are then handled (E_STRICT becomesE_ERRORor the
feature is removed entirely) with the future releases. I think a clear,
written down policy is needed (and as always may be overwritten via
common sense on a case by case basis).regards,
Lukas
Pierre wrote:
Hello,
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
Hello,
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?
I don't like new keywords either, but I don't see any alternative. I
also think that interfaces are what should be used. But it seems that
we are wrong, interfaces do not solve this issue, I'm still unsure
about the reasons though...
--Pierre
Pierre wrote:
I don't like new keywords either, but I don't see any alternative. I
also think that interfaces are what should be used. But it seems that
we are wrong, interfaces do not solve this issue, I'm still unsure
about the reasons though.
Not that I am advocating this, but
class Foo implements PHP_StrictMode {}
could imply the same semantics as
strict class Foo {}
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Hello,
Pierre wrote:
I don't like new keywords either, but I don't see any alternative. I
also think that interfaces are what should be used. But it seems that
we are wrong, interfaces do not solve this issue, I'm still unsure
about the reasons though.Not that I am advocating this, but
What are you advocating then? Do you have an opinion? ;-)
class Foo implements PHP_StrictMode {}
could imply the same semantics as
strict class Foo {}
Please tell me what we are missing then. It has been said that
interface does not solve this problem.
--Pierre
Pierre wrote:
What are you advocating then? Do you have an opinion? ;-)
No, at the moment I do not have an opinion on this.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Pierre wrote:
Hello,
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?I don't like new keywords either, but I don't see any alternative. I
also think that interfaces are what should be used. But it seems that
we are wrong, interfaces do not solve this issue, I'm still unsure
about the reasons though...
Well, currently they don't because they don't care about method
signatures, but they could be made to care. Are there reasons beyond that?
-Rasmus
If "use interfaces" means that i have to write an interface matching
every public method in my class if i want that strict mode, and
another interface for every inheriting class that adds method, then
that is not a solution. That means code duplication ...
Regards,
Stefan
Rasmus Lerdorf wrote:
Pierre wrote:
Hello,
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?I don't like new keywords either, but I don't see any alternative. I
also think that interfaces are what should be used. But it seems that
we are wrong, interfaces do not solve this issue, I'm still unsure
about the reasons though...Well, currently they don't because they don't care about method
signatures, but they could be made to care. Are there reasons beyond that?
erm, interfaces do care about method signatures either that or my php5 install
is magic:
php5 -r '
interface Foo { function bar($v, $k); } class Qux implements Foo { function bar() {} }'
Fatal error: Declaration of Qux::bar() must be compatible with that of Foo::bar() in Command line code on line 2
php5 -r '
interface Foo { function bar($v, $k); } class Qux implements Foo { function bar($a, $b, $c) {} }'
Fatal error: Declaration of Qux::bar() must be compatible with that of Foo::bar() in Command line code on line 2
-Rasmus
Pierre 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?
There is however a problem with this approach:
You would still need to modify code in order to get things "strict".
Take for example some code that I have running (and want to keep
running) on PHP 5.1. If in 5.2 we suddendly need to implement a specific
interface in order to get strict behavior this code will no longer run
on PHP 5.1 (without hacks). The other option is not to mark things as
strict but that can makes things a bitch to debug. However, if we follow
Zeev's proposal then there are no real problems at all - technical wise.
Only having to ignore E_STRICT in case your apps are violating some core
OO rules is then necessary. Splitting out E_STRICT into different error
levels might work as well, but I am not so sure if that is necessary. So
let me sum up the things from Zeev's proposal) and dropping his 4th
point from it.
- 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
I think this is perfectly acceptable as it address both the people who
want strictess, without having to change any code, and the people who do
not care about it, which can simply ignore E_STRICT then.
regards,
Derick
Derick Rethans wrote:
- 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
i am fine with that proposal .. if we do split up E_STRICT into E_STRICT
(feature is not clean "proper" code) and E_DEPRECATED (feature will be
dropped in the next major release)
also note that the first two points in Derick's list only apply to
classes on the C level .. userland classes will only trigger E_STRICT if
they are improperly overwritten.
will it be possible to get the information about the strictness of
internal classes via the reflection API? or will we leave this to
documentation only?
regards,
Lukas
At 10:49 04/08/2006, Lukas Smith wrote:
Derick Rethans wrote:
- 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_STRICTi am fine with that proposal .. if we do split up
E_STRICTinto
E_STRICT (feature is not clean "proper" code) andE_DEPRECATED
(feature will be dropped in the next major release)also note that the first two points in Derick's list only apply to
classes on the C level .. userland classes will only trigger
E_STRICT if they are improperly overwritten.
It's my list actually, so I'm definitely +1 on that :)
Zeev
Zeev Suraski wrote:
It's my list actually, so I'm definitely +1 on that :)
Sorry, did not want to take away credit from you Zeev :)
regards,
Lukas
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'
Hello,
Would exposing this flag to the user at method level get a bit verbose
for those who want to use it? Perhaps a class level flag for all
methods? Wasn't that proposed earlier? Its a long thread to follow,
forgive me if I've missed something.
Best Regards,
Jeff
Jeff Moore wrote:
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'Hello,
Would exposing this flag to the user at method level get a bit verbose
for those who want to use it? Perhaps a class level flag for all
methods? Wasn't that proposed earlier? Its a long thread to follow,
forgive me if I've missed something.
Yeah if we do allow a flag for methods, then we should also have one for
the entire class. But if we reuse the "interface" keyword things will
get tricky. I doubt the strict camp wants to allow people to add method
bodies in interfaces and "class interface foo {}" looks odd too.
regards,
Lukas
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'Would exposing this flag to the user at method level get a bit verbose
for those who want to use it? Perhaps a class level flag for all
methods? Wasn't that proposed earlier? Its a long thread to follow,
forgive me if I've missed something.
strict class blah blah blah { }
as shorthand for:
class blah blah blah { [strict function (){}]* }
doesn't seem like it would be too terribly difficult to implement or
understand...
Though 'strict' may not be the right keyword...
method_signature_match is a bit too verbose, though :-)
sigmatch ???
'strict' just has too many other potential meanings...
--
Like Music?
http://l-i-e.com/artists.htm
Hello Richard,
strict would meann a new keyword which most likely breaks a bunch of
applications. It would be much easier to do:
class Foo implements Strict { }
and for the methods only stick with 'interface'.
best regards
marcus
Monday, August 7, 2006, 8:29:09 PM, you wrote:
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'Would exposing this flag to the user at method level get a bit verbose
for those who want to use it? Perhaps a class level flag for all
methods? Wasn't that proposed earlier? Its a long thread to follow,
forgive me if I've missed something.
strict class blah blah blah { }
as shorthand for:
class blah blah blah { [strict function (){}]* }
doesn't seem like it would be too terribly difficult to implement or
understand...
Though 'strict' may not be the right keyword...
method_signature_match is a bit too verbose, though :-)
sigmatch ???
'strict' just has too many other potential meanings...
--
Like Music?
http://l-i-e.com/artists.htm
Best regards,
Marcus
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
Hello Richard,
Wednesday, August 2, 2006, 11:55:45 PM, you 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
Hello Richard,
Wednesday, August 2, 2006, 11:55:45 PM, you 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
At 01:06 03/08/2006, Marcus Boerger wrote:
Hello Richard,
Wednesday, August 2, 2006, 11:55:45 PM, you 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
At 00:55 03/08/2006, Richard Lynch 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_ERRORis not issued without the extra keyword
E_STRICT, which is new anyway, is issued without the extra keywordSo, it would seem, that the extra keyword should be 'loose' and would
suppress theE_STRICTyou 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 issueE_STRICTAt no time in a future release will E issue
E_ERRORinstead of
E_STRICT -- This construct will remain inE_STRICTpurgatory for all
time.Purists who run under
E_STRICTget 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
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 andPHP 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
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
Stefan Walk wrote:
For the people who have said "I can not understand why this is a bad
thing":
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
For the people who have said "I can not understand why this is a bad
thing":
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
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. |
`---------------------------------------------'
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
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. |
`------------------------------------------------------------'
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
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
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
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
Derick Rethans 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:
-
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. -
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
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...
Derick Rethans 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:
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.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,
Lukasregards,
Lukas
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
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).
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
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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
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!
This would require an almost 100% rewrite ...
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Richard Quadling wrote:
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.
totally changing the underlying type concept in an incompatible
way is not refactoring, and even as a rewrite i'm strongly in doubt
whether the result deserves to go by the same name as the original
We have OOP developers wanting OOP things that they've seen working
fine in other languages and non-OOP'ers wondering why!
Is function overloading really "an OOP thing"?
As this is a discussion forum, all things SHOULD be considered!
There is a difference between discussion and brainstorming ...
--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
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
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
Derick Rethans 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
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
At 12:44 02/08/2006, Lukas Smith wrote:
Derick Rethans 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
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.
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_STRICTenabled and have
their codeE_STRICTclean, so providing userland support for tagging
classes/methods as strict is probably not really necessary.Zeev
--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
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
strictMost people who use 'strict OO' will have
E_STRICTenabled and have
their codeE_STRICTclean, 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.
Zeev
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
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
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. |
`------------------------------------------------------------'
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,
Except that I would prefer the other way 'round. The default should be
the "loose one".
--Pierre
At 18:22 02/08/2006, Pierre 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,
Except that I would prefer the other way 'round. The default should be
the "loose one".
Yes, that's what I originally meant. And as I mentioned, in my
opinion that's not really all that necessary. Those who care about
this kind of stuff will tend to have E_STRICT enabled and will fix it anyway.
Zeev
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
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_STRICTenabled and have
their codeE_STRICTclean, so providing userland support for tagging
classes/methods as strict is probably not really necessary.Zeev
At 10:41 02/08/2006, Derick Rethans wrote:
Hello Michael,
nobody forces you to use OO if you don't like it but it is as
it is. AndIt 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
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
At 15:49 02/08/2006, Derick Rethans 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
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
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