On Fri, November 3, 2006 12:11 pm, Marcus Boerger wrote:
> In PHP it might work
> as
> expected but then all programmers that come from langiages like C++
> get
> confused.
I'm sorry, but, really, I'm not interested in crippling PHP to cater
to C++ converts... :-) :-) :-)
I don't think this is a
Hello Jeff,
Sunday, November 5, 2006, 7:09:26 PM, you wrote:
> On Nov 3, 2006, at 1:11 PM, Marcus Boerger wrote:
>> Liskov applies to static methods as soon as calls via objects are common
>> which is true for PHP. Actually in PHP static methods are inherited as any
>> other method (also true
On Nov 3, 2006, at 1:11 PM, Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are
common
which is true for PHP. Actually in PHP static methods are inherited as
any
other method (also true for a lot of other languages). Now given Liskov
rules you can as well
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
I didn't say it is good practice, god behave :-)
So you're a
Hello Christian,
Saturday, November 4, 2006, 5:13:32 PM, you wrote:
> Marcus Boerger wrote:
>> Liskov applies to static methods as soon as calls via objects are common
>> which is true for PHP.
> This is common in PHP and you consider this good practice? Interesting,
> wasn't what I would ha
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
Now given Liskov
rules you can as well add default parameter
Hello Christian,
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP. Actually in PHP static methods are inherited as any
other method (also true for a lot of other languages). Now given Liskov
rules you can as well add default parameter values as add n
Ilia Alshanetsky wrote:
> Thanks to Hannes we have a fairly complete list of changes in the error
> conditions, so far people who have commented out it did not appear to
> have identified anything objectionable. We need to make a decision on
> how to proceed, either to roll 5.2.0 now or wait anothe
Thanks to Hannes we have a fairly complete list of changes in the
error conditions, so far people who have commented out it did not
appear to have identified anything objectionable. We need to make a
decision on how to proceed, either to roll 5.2.0 now or wait another
week. My vote is to ro
Hello Ilia,
both, the __toString and the iterator in foreach by reference would put
the engine into an unstable state. That saiditis very important that we do
not blindley change error modes here. Most changes havebeen done for a good
reason. And most of those were added lately because we are al
Right.
Zeev
At 17:13 24/10/2006, Ilia Alshanetsky wrote:
Some OO errors like using iterators by reference and throwing
exceptions out of __toString() are ligit as well, doing so would/
could cause problems.
On 24-Oct-06, at 11:10 AM, Zeev Suraski wrote:
I think that a lot of those are leg
Some OO errors like using iterators by reference and throwing
exceptions out of __toString() are ligit as well, doing so would/
could cause problems.
On 24-Oct-06, at 11:10 AM, Zeev Suraski wrote:
I think that a lot of those are legit - we only need to 'demote'
the language-level warnings/
I think that a lot of those are legit - we only need to 'demote' the
language-level warnings/errors that attempt to enforce strict OO standards.
Warnings/errors that warn about unacceptable input are legitimate and
should stay.
Zeev
At 16:57 24/10/2006, Hannes Magnusson wrote:
On 10/24/06, Il
On 10/24/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some
of which cannot be delegated to lower error reporting modes as they
may cause engine instability or similar problems. Rasmus was going to
make a list of all the ne
Well I'm definitely not referring to those, only the new strict OO
fatals as per Marcus's original message...
Zeev
At 16:32 24/10/2006, Ilia Alshanetsky wrote:
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some
of which cannot be delegated to lower error reporting mod
Ilia Alshanetsky wrote:
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some of
which cannot be delegated to lower error reporting modes as they may
cause engine instability or similar problems. Rasmus was going to make a
list of all the newly added engine error changes
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some
of which cannot be delegated to lower error reporting modes as they
may cause engine instability or similar problems. Rasmus was going to
make a list of all the newly added engine error changes, hopefully
he'll ha
For this particular purpose there is a fairly detailed
README.UPDATE_5_2 that details the major functionality changes that
have happened in PHP 5.2
On 24-Oct-06, at 12:17 AM, Lester Caine wrote:
Ilia Alshanetsky wrote:
I've been reading people's replies to Marcus' RFC in regard to
E_DEPR
Zeev Suraski wrote:
Ilia,
I think Wez's suggestion is the most practical one. Let's make sure we
haven't introduced any fatal errors into 5.2 (and demote them to
E_STRICT for now), and handle the rest of the suggestions afterwards.
+1
I guess this is the best we can go. It might cause some
Ilia,
I think Wez's suggestion is the most practical one. Let's make sure
we haven't introduced any fatal errors into 5.2 (and demote them to
E_STRICT for now), and handle the rest of the suggestions afterwards.
Zeev
At 02:33 24/10/2006, Ilia Alshanetsky wrote:
I've been reading people's r
Ilia Alshanetsky wrote:
I've been reading people's replies to Marcus' RFC in regard to
E_DEPRECATED and it seems that some people have expressed the want to
delay 5.2 until mucking around with error handling is done one way or
another. My simple answer to this is no.
SIMPLE QUESTION - I've ju
I've been reading people's replies to Marcus' RFC in regard to
E_DEPRECATED and it seems that some people have expressed the want to
delay 5.2 until mucking around with error handling is done one way or
another. My simple answer to this is no.
The long answer is as follows.
PHP 5.2.0 is no
22 matches
Mail list logo
