Hi!
The PHP 5.3 compatibility issue for the Drupal CMS
(http://drupal.org/node/360605), for example, had over 200 comments, and
it took about 9 months before a patch was committed to the current
version of Drupal in September (see comment 158). That's not the only
example, but it's a prominent
On Tue, Dec 29, 2009 at 3:01 AM, Etienne Kneuss col...@php.net wrote:
Hi,
On Tue, Dec 29, 2009 at 1:27 AM, Clint Priest cpri...@warpmail.net wrote:
Etienne Kneuss wrote:
On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest cpri...@warpmail.net
wrote:
Unfortunately $x instanceOf ArrayAccess
On Thu, Dec 31, 2009 at 7:10 AM, Stanislav Malyshev s...@zend.com wrote:
Hi!
One of the many things that is chaotic in PHP is what internal function
returns when invalid parameters are given (i.e. params parsing fails). Most
of those functions do one of:
1a. just return - this happens with
Those things were already deprecated, it's good thing that php 5.3
finally broke bad code, php 5 (since the first alpha) is there since a
while, drupal is drupal if folks don't want to fix it, what's the big
deal there? just pach it yourself it's open source isn't it? so
nothing stop you to fork,
2009/12/31 Alexey Zakhlestin indey...@gmail.com:
On Thu, Dec 31, 2009 at 7:10 AM, Stanislav Malyshev s...@zend.com wrote:
Hi!
One of the many things that is chaotic in PHP is what internal function
returns when invalid parameters are given (i.e. params parsing fails). Most
of those functions
Hi!
Would changing the returning value to Null to indicate invalid
arguments (or any other error condition) would create a significant BC
surely? Just how many functions are documented with the entity
return.falseforfailure;? (198 files using this so far vs Return
null; which is used very
2009/12/31 Stanislav Malyshev s...@zend.com:
Hi!
Would changing the returning value to Null to indicate invalid
arguments (or any other error condition) would create a significant BC
surely? Just how many functions are documented with the entity
return.falseforfailure;? (198 files using this
On Thu, 31 Dec 2009, Stanislav Malyshev wrote:
Would changing the returning value to Null to indicate invalid
arguments (or any other error condition) would create a significant BC
surely? Just how many functions are documented with the entity
return.falseforfailure;? (198 files using
At 14:20 31/12/2009, Derick Rethans wrote:
On Thu, 31 Dec 2009, Stanislav Malyshev wrote:
Would changing the returning value to Null to indicate invalid
arguments (or any other error condition) would create a significant BC
surely? Just how many functions are documented with the entity
On Thu, 2009-12-31 at 12:20 +, Derick Rethans wrote:
Hmm, I don't actually think many people test whether parsing parameters
failed, but they do test the return value. AFAIK, our standard is to
return NULL for parameter parsing failures (at least that's what all the
examples in
On Dec 31, 2009, at 5:22 AM, Johannes Schlüter wrote:
On Thu, 2009-12-31 at 12:20 +, Derick Rethans wrote:
Hmm, I don't actually think many people test whether parsing parameters
failed, but they do test the return value. AFAIK, our standard is to
return NULL for parameter parsing
The change is specific to :: since that is used for classes and causes
confusion as people may think foo::bar will allow definition or
re-definition of a class constant which it does not.
On 09-12-30 2:42 PM, Johannes Schlüter wrote:
Hi,
On Wed, 2009-12-30 at 19:15 +, Ilia Alshanetsky
Hi!
This is also the documented as the general convention:
http://de.php.net/manual/en/functions.internal.php
While there are exceptions to this on purpose: For instance get_object
is documented to Return FALSE if /object/ is not an object (this
exception was discussed in detail in the past)
13 matches
Mail list logo
