Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
David Muir wrote: Personally I think that the main issue is that we silently convert $foo['bar'] to $foo[0] for strings, which imo rarely the intended behavior and doesn't really makes much sense (except that the offset expects the index to be int, and this is how we type juggle between string and int), so I think it would be a good idea to raise a notice here, so the developer can fix his code, or add some input validation. That would be a help. That would help a lot ... this is not a problem of so the developer can fix his code but rather so we can fix legacy code which other non-developers are currently using happily ... If *I* had written the code I would not have done it the way it is currently structured, but I'm not about to spend time re-engineering it ... I just want to plug the holes quickly so it continues to work. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi! That would help a lot ... this is not a problem of so the developer can fix his code but rather so we can fix legacy code which other non-developers are currently using happily ... If *I* had written the code I would not have done it the way it is currently structured, but I'm not about to spend time re-engineering it ... I just want to plug the holes quickly so it continues to work. OK, notice is probably technically feasible, though I still not like the idea too much. When you want to produce this notice? Producing it on any string would probably break code like $a['1'] which has it's legitimate uses and I'm sure can be seen around. Should be produce notice if the string has non-numeric chars? That's slow down this operation a little, though probably not critically as conversion is going to scan the string anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 3:41 AM, David Muir davidkm...@gmail.com wrote:
On 24/11/11 12:44, Ferenc Kovacs wrote:
On Thu, Nov 24, 2011 at 1:38 AM, David Muir davidkm...@gmail.com wrote:
Just to clarify, the changes introduced in 5.4 will result in the
following:
?php
$string = 'foo';
$array = array(
'foo' = array(
'bar' = 'baz',
//expected structure
//'bar' = array('baz' = array('values'))
));
var_dump(
isset($string['foo']), //true
isset($string[0][0]), //false, true in 5.4
isset($array['foo']['bar'][0]), //true
isset($array['foo']['bar']['baz']), //true
isset($array['foo']['bar']['baz']['0']) //false, true as of 5.4
isset($string['foo']['bar']['baz']['0']) //false, true as of 5.4
);
you are missing a comma from the end of the
isset($array['foo']['bar']['baz']['0']) //false, true as of 5.4
line
Yeah, I added that one at the last minute. That's what I get for a quick
copy/paste...
isset($string['foo']['bar']['baz']['0']) //false, true as of 5.4
gives me a fatal error on 5.3 (PHP Fatal error: Cannot use string offset
as an array as you can't chain string offsets before 5.4)
It gives me false in 5.3.6. Using it outside of isset() results in the
fatal error.
hm.
tyrael@thor:~$ php -r '$string =
foo;isset($string[foo][bar][baz][0]);';
PHP Fatal error: Cannot use string offset as an array in Command line code
on line 1
tyrael@thor:~$ php -v
PHP 5.3.8-1~dotdeb.2 with Suhosin-Patch (cli) (built: Aug 25 2011 13:30:46)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
I will check this against a vanilla version, as there is a chance that
either dotdeb(less likely) or suhosin patched something.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Stas Malyshev wrote: Hi! That would help a lot ... this is not a problem of so the developer can fix his code but rather so we can fix legacy code which other non-developers are currently using happily ... If *I* had written the code I would not have done it the way it is currently structured, but I'm not about to spend time re-engineering it ... I just want to plug the holes quickly so it continues to work. OK, notice is probably technically feasible, though I still not like the idea too much. When you want to produce this notice? Producing it on any string would probably break code like $a['1'] which has it's legitimate uses and I'm sure can be seen around. Should be produce notice if the string has non-numeric chars? That's slow down this operation a little, though probably not critically as conversion is going to scan the string anyway. The 'index not found' error usually pops up where I'm messing up the existing 'logic' so something that flags that a 'phantom' index has been created when a 'real' ['sub-element'] was being looked for. In my own case I'm sure once I dig out the problem the answer will be obvious as well, but I simply don't have the time to spend. So currently a production 5.4 upgrade is not possible. It would be useful if some of the other people flagging this problem could provide some info on what is failing ... the original PEAR problem for example? I'm not sure that any of us know just what edge case is causing a hickup? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Ferenc Kovacs wrote: I will check this against a vanilla version, as there is a chance that either dotdeb(less likely) or suhosin patched something. I had a look, my SUSE boxes have suhosin on still, but the 5.3 test machine is running windows without it ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Ferenc Kovacs wrote: I will check this against a vanilla version, as there is a chance that either dotdeb(less likely) or suhosin patched something. I had a look, my SUSE boxes have suhosin on still, but the 5.3 test machine is running windows without it ... 5.4 machine even ... the SUSE boxes are 5.3 ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 10:32 AM, Lester Caine les...@lsces.co.uk wrote: Stas Malyshev wrote: Hi! That would help a lot ... this is not a problem of so the developer can fix his code but rather so we can fix legacy code which other non-developers are currently using happily ... If *I* had written the code I would not have done it the way it is currently structured, but I'm not about to spend time re-engineering it ... I just want to plug the holes quickly so it continues to work. OK, notice is probably technically feasible, though I still not like the idea too much. When you want to produce this notice? Producing it on any string would probably break code like $a['1'] which has it's legitimate uses and I'm sure can be seen around. Should be produce notice if the string has non-numeric chars? That's slow down this operation a little, though probably not critically as conversion is going to scan the string anyway. The 'index not found' error usually pops up where I'm messing up the existing 'logic' so something that flags that a 'phantom' index has been created when a 'real' ['sub-element'] was being looked for. In my own case I'm sure once I dig out the problem the answer will be obvious as well, but I simply don't have the time to spend. So currently a production 5.4 upgrade is not possible. It would be useful if some of the other people flagging this problem could provide some info on what is failing ... the original PEAR problem for example? I'm not sure that any of us know just what edge case is causing a hickup? Without debugging the exact problem or having a script replicating the different behavior between 5.3. and 5.4, your feedback doesn't really provide anything valuable, as it can be caused by this change, or something else. We only aware of two behavior difference between 5.3 and 5.4 related to this particular change: - offset chaining works now, while it was throwing a fatal error in 5.3 ($string[0][0][0] returns the first character of $string) - which means that the type juggling behavior (unrelated to this change, also exists in 5.3) can occur not just for $string['foo'] but for $array['string_exists_where_array_expected']['foo'] also (this is what Daniel bumped into in the PEAR tests). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 24 November 2011 01:38, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
But neither is introducing a potential bomb of the kind that the 'date'
saga
created. The problem this change IS causing is likely to hit many live
sites
The claim that many live sites actually regularly use string multiple string
offsets to distinguish strings from arrays sounds implausible to me.
Hi,
I hadn't the opportunity to install php 5.4 to test this, so I was
wondering if someone could test how would this code behave ?
###
if (
!isset( $widget_options['dashboard_incoming_links'] )
|| !isset( $widget_options['dashboard_incoming_links']['home'] )
|| $widget_options['dashboard_incoming_links']['home'] != get_option('home') )
###
Is that correct saying that if the first condition is false the second
will always be true ?
Note: that's a piece of Wordpress
Thank you
Devis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
-Original Message-
From: Gustavo Lopes [mailto:glo...@nebm.ist.utl.pt]
Sent: 23 November 2011 22:31
On Wed, 23 Nov 2011 21:06:09 -, Pierre Joye
pierre@gmail.com
wrote:
The fact that we have reports here showing code not working
anymore
because of this change tells me that it is a BC break. We can call
it
a bug fix but it still breaks code out there for no real benefit
but
edge case usages. We had this situation before, that does not help
us.
I'd say for no benefit at all. Why would anyone ever want to take a
string
offset from a string that certainly has length 1? Except for taking
satisfaction in this improved consistency, I see absolutely no
benefit.
Up until now, it was deemed a useless but innocuous change. Now that
we
found it has pernicious side effects, we ought to revert it.
That's exactly my take on it. As far as I can see, if 5.4 is released
with this fix in, it will effectively be rendered a non-upgradable-to
version for most big projects.
For what it's worth (not much!), my two pennorth on this is that
whilst, like some others, I can see the marginal benefit of making the
behaviour consistent, I really don't think the change can be done in
one go. Given that this WILL break existing code (some of it mine :( ),
there needs to be a release where the usage generates an error message
- probably an E_WARNING, or maybe an E_STRICT - and an easy alternative
is provided. Since the simplest alternative way of performing the
necessary chained checks would seem to be:
if (is_array($arr) array_key_exists('key1', $arr)
is_array($arr['key1'] array_key_exists('key2', $arr['key2'])
...
)
which substitutes 2 function calls and 2 array accesses per dimension
for a single function call and 1 multi-dimensional array access, there has
to be scope for a function called something like array_offset_exists with
a signature like
array_offset_exists(array $array, mixed $offset, ...)
(Yes, I know, inconsistent argument order and all that, but)
so that people can have a chance to transform
isset($arr['key1']['key2']['key3'])
into
array_offset_exists($arr, 'key1', 'key2, 'key3')
before the full fix is put into place in a subsequent version.
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
It gives me false in 5.3.6. Using it outside of isset() results in the fatal error. hm. tyrael@thor:~$ php -r '$string = foo;isset($string[foo][bar][baz][0]);'; PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 tyrael@thor:~$ php -v PHP 5.3.8-1~dotdeb.2 with Suhosin-Patch (cli) (built: Aug 25 2011 13:30:46) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH I will check this against a vanilla version, as there is a chance that either dotdeb(less likely) or suhosin patched something. I just remembered that there is http://codepad.viper-7.com/ so: 5.3 - fatal error: http://codepad.viper-7.com/GGhoSn 5.4 - works: http://codepad.viper-7.com/WRdyni -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
2011/11/24 de...@lucato.it:
On 24 November 2011 01:38, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
But neither is introducing a potential bomb of the kind that the 'date'
saga
created. The problem this change IS causing is likely to hit many live
sites
The claim that many live sites actually regularly use string multiple string
offsets to distinguish strings from arrays sounds implausible to me.
Hi,
I hadn't the opportunity to install php 5.4 to test this, so I was
wondering if someone could test how would this code behave ?
Hi, Davis, first of all you can use this service:
http://codepad.viper-7.com/ to test your code against 5.2, 5.3, 5.4
and latest trunk.
###
if (
!isset( $widget_options['dashboard_incoming_links'] )
|| !isset( $widget_options['dashboard_incoming_links']['home'] )
|| $widget_options['dashboard_incoming_links']['home'] != get_option('home')
)
###
Is that correct saying that if the first condition is false the second
will always be true ?
Note: that's a piece of Wordpress
About your question if I understand it correctly: if
$widget_options['dashboard_incoming_links'] is not set, then
$widget_options['dashboard_incoming_links']['home'] can't be set in
any conditions.
Thank you
Devis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Regards,
Shein Alexey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
2011/11/24 de...@lucato.it:
On 24 November 2011 01:38, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi,
I hadn't the opportunity to install php 5.4 to test this, so I was
wondering if someone could test how would this code behave ?
###
if (
!isset( $widget_options['dashboard_incoming_links'] )
|| !isset( $widget_options['dashboard_incoming_links']['home'] )
|| $widget_options['dashboard_incoming_links']['home'] != get_option('home')
)
###
Is that correct saying that if the first condition is false the second
will always be true ?
Note: that's a piece of Wordpress
[yohgaki@dev php-src-5.4]$ ./php -r 'var_dump(!isset($a[a][a]));'
bool(true)
[yohgaki@dev php-src-5.4]$ ./php -r '$a =
[a=[a=1]];var_dump(!isset($a[a]), $a);'
bool(false)
array(1) {
[a]=
array(1) {
[a]=
int(1)
}
}
[yohgaki@dev php-src-5.4]$ ./php -r '$a =
[a=[a=1]];var_dump(!isset($a[a][a]), $a);'
bool(false)
array(1) {
[a]=
array(1) {
[a]=
int(1)
}
}
So it's not always true.
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 11:05 AM, de...@lucato.it wrote:
On 24 November 2011 01:38, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
But neither is introducing a potential bomb of the kind that the 'date'
saga
created. The problem this change IS causing is likely to hit many live
sites
The claim that many live sites actually regularly use string multiple
string
offsets to distinguish strings from arrays sounds implausible to me.
Hi,
I hadn't the opportunity to install php 5.4 to test this, so I was
wondering if someone could test how would this code behave ?
###
if (
!isset( $widget_options['dashboard_incoming_links'] )
|| !isset( $widget_options['dashboard_incoming_links']['home'] )
|| $widget_options['dashboard_incoming_links']['home'] !=
get_option('home') )
###
Is that correct saying that if the first condition is false the second
will always be true ?
Note: that's a piece of Wordpress
hi.
you can also test it http://codepad.viper-7.com/ if you don't want/can't
have a build from source.
What does get_option('home') return?
From a quick glance, I think that you are safe, except if you get a string
instead of an array(either for $widget_options
or $widget_options['dashboard_incoming_links']), and the first character of
that string is a slash and your get_option('home') returns a slash also.
in which case your code will behave as it would get a correct array
having $widget_options['dashboard_incoming_links']['home'] = '/'
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 11:31 AM, Ford, Mike m.f...@leedsmet.ac.uk wrote: -Original Message- From: Gustavo Lopes [mailto:glo...@nebm.ist.utl.pt] Sent: 23 November 2011 22:31 On Wed, 23 Nov 2011 21:06:09 -, Pierre Joye pierre@gmail.com wrote: The fact that we have reports here showing code not working anymore because of this change tells me that it is a BC break. We can call it a bug fix but it still breaks code out there for no real benefit but edge case usages. We had this situation before, that does not help us. I'd say for no benefit at all. Why would anyone ever want to take a string offset from a string that certainly has length 1? Except for taking satisfaction in this improved consistency, I see absolutely no benefit. Up until now, it was deemed a useless but innocuous change. Now that we found it has pernicious side effects, we ought to revert it. That's exactly my take on it. As far as I can see, if 5.4 is released with this fix in, it will effectively be rendered a non-upgradable-to version for most big projects. we yet to see such a project. for example the ZF testsuite was ran against the RC1, and didn't bumped into this. we also run the symfony2 testsuite on ci.qa.php.net and the test results seems to be consistent between 5.3, 5.4 and trunk http://ci.qa.php.net/view/php-userland/job/php-symfony2/362/testReport/? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Changes to constructor signature checks
On 23 November 2011 18:37, Anthony Ferrara ircmax...@gmail.com wrote:
Ralph:
From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but whatever). Additionally, since it's not
enforced, perhaps an E_DEPRECATED or E_STRICT error should be raised
on definition, as it is superfluous...
Option 2. Fix grandchild signature checking to be inline for how
signatures work with other methods.
Personally, I think option 2 is the better one. I see it being odd
and inconsistent that all methods work one way, and constructors work
differently. But that's just my feeling (and I know others disagree
there).
And please don't reduce the error level of a signature change (as it
would introduce even more inconsistency)...
Just my $0.02...
Anthony
On Wed, Nov 23, 2011 at 1:25 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Internals:
Time to summarize.
It is clear to me that internals is divided on this issue. I don't think
it's a large enough issue to drag on, even when I disagree with it - both
theoretically and in practice.
For most OO developer, putting ctors as an abstract or in an interface would
not happen anyway, so this does not affect them.
** The current change represents a minor break in BC, that should be noted
in the manual. **
Also, a decision needs to be made on what to do with grandchildren. As I
mentioned, the following produces no E_FATAL and no warnings:
abstract class A { abstract public function __construct($a, $b); }
class B extends A { public function __construct($a, $b) {} }
class C extends B { public function __construct(ArrayObject $d) {}
While this is correct behavior to me (ability for concrete to use its own
ctor), using the *current logic* strict signature checking enforced from an
abstract, then the above is also wrong.
** Can we decide what to do with that situation? **
On 11/18/11 5:05 AM, Pierre Joye wrote:
I strongly disagree, this encourages bad practices. We could however
reduce the error level to warning.
I think this is a sufficient compromise- I don't see anything E_FATAL about
a signature change in ctors (I actually see nothing wrong with it, but it's
clear the community is divided there).
** Can we make that change? **
Thanks,
-ralph
What is the normal way for userland developers to learn about
constructors? Do they know about LSP? If they do, does it apply to
constructors?
A comment on StackOverflow [1]
At its heart LSP is about interfaces and contracts as well as how to
decided when to extend a class vs. use another strategy such as
composition to achieve your goal.
I am self taught. It was always my understanding that the constructor
was special in that it is, essentially, a magic method that can only
respond to the new keyword. Being able to call the constructor
directly, ..., that does feel a little odd as I can't actually
construct a new instance that way.
Using an interface to enforce the sig is fine. That's the exact nature
of an interface, to enforce the contract by design and if the
StackOverflow comment is accurate, then my understanding of interfaces
is fine with regard to LSP.
An abstract class, by its very nature is not formed. It isn't a
contract. It is an idea and the concrete doesn't need to fit
perfectly. OK. There is some things that are fixed, method signatures
most accept the parameters defined in the subclass but can add more
(as I understand things).
But is the signature of the constructor in an abstract class to be
enforced? I feel that it shouldn't be. It is a special method.
WikiPedia [2] has an article on Constructor Overloading. It says
Constructors, used to create instances of an object, may also be
overloaded in some object oriented programming languages.. OK, so
WikiPedia may have a different opinion tomorrow.
Whilst we don't support overloading in the same way (I think we can
simulate it with __call() easily enough with ReflectionParameter being
my friend here maybe).
We, DO, provide the tools to allow overloading and non LSP coding
practises. Is it a great leap to also allow the same flexibility with
constructors?
Regards,
Richard Quadling.
[1]
http://stackoverflow.com/questions/56860/what-is-the-liskov-substitution-principle
[2] http://en.wikipedia.org/wiki/Constructor_overloading#Constructor_overloading
--
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
fan.sh/6/370
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Just a quick note for this issue. If I remember correctly, PHP is working this way at least from PHP 3.0.x. $a[123] // integer index $a['123'] // integer index $a['123 abc'] // string index $a['123.123'] // string index Automatic string to integer conversion only happened if index string has numeric chars. It seems some people are confused. isset($a[0][0]) became true if and only if $a is string. If there is a code broken by this behavior, it would be enough for add is_array() if (is_array($a) isset($a[0][0])) I suppose. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3.9RC today too?
Hi Johannes, Any plan to package the RC today? it has been a while since the last RC. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.9RC today too?
RC2 is in the tags, so I guess its because it hasnt hit all the mirrors yet 2011/11/24 Pierre Joye pierre@gmail.com Hi Johannes, Any plan to package the RC today? it has been a while since the last RC. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.9RC today too?
2011/11/24 Keloran ava...@gmail.com: RC2 is in the tags, so I guess its because it hasnt hit all the mirrors yet No, there is no 5.3.9 RC2 tag -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.9RC today too?
sorry, i read the RC2 part, not the 5.3.9 part my bad 2011/11/24 Johannes Schlüter johan...@schlueters.de On Thu, 2011-11-24 at 12:22 +0100, Pierre Joye wrote: Hi Johannes, Any plan to package the RC today? it has been a while since the last RC. Cheers, Yes, that's the plan. I tried doing it last week but didn't reach you. Will be on IRC in a moment. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changes to constructor signature checks
Something else to consider:
Right now, Constructors are checked on interfaces. See the following
two examples:
http://codepad.viper-7.com/9IAGNP
http://codepad.viper-7.com/edokLi
So right now, interfaces are enforcing constructors fully (in 5.3).
Which makes more sense: Having abstract methods behaving the same as
the interface declaration (to grand-children, etc), or having abstract
declarations behave differently and ignoring abstract constructors?
My vote is for consistency (since the concept between abstract methods
and interface methods is very similar)...
Anthony
On Thu, Nov 24, 2011 at 5:48 AM, Richard Quadling rquadl...@gmail.com wrote:
On 23 November 2011 18:37, Anthony Ferrara ircmax...@gmail.com wrote:
Ralph:
From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but whatever). Additionally, since it's not
enforced, perhaps an E_DEPRECATED or E_STRICT error should be raised
on definition, as it is superfluous...
Option 2. Fix grandchild signature checking to be inline for how
signatures work with other methods.
Personally, I think option 2 is the better one. I see it being odd
and inconsistent that all methods work one way, and constructors work
differently. But that's just my feeling (and I know others disagree
there).
And please don't reduce the error level of a signature change (as it
would introduce even more inconsistency)...
Just my $0.02...
Anthony
On Wed, Nov 23, 2011 at 1:25 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Internals:
Time to summarize.
It is clear to me that internals is divided on this issue. I don't think
it's a large enough issue to drag on, even when I disagree with it - both
theoretically and in practice.
For most OO developer, putting ctors as an abstract or in an interface would
not happen anyway, so this does not affect them.
** The current change represents a minor break in BC, that should be noted
in the manual. **
Also, a decision needs to be made on what to do with grandchildren. As I
mentioned, the following produces no E_FATAL and no warnings:
abstract class A { abstract public function __construct($a, $b); }
class B extends A { public function __construct($a, $b) {} }
class C extends B { public function __construct(ArrayObject $d) {}
While this is correct behavior to me (ability for concrete to use its own
ctor), using the *current logic* strict signature checking enforced from an
abstract, then the above is also wrong.
** Can we decide what to do with that situation? **
On 11/18/11 5:05 AM, Pierre Joye wrote:
I strongly disagree, this encourages bad practices. We could however
reduce the error level to warning.
I think this is a sufficient compromise- I don't see anything E_FATAL about
a signature change in ctors (I actually see nothing wrong with it, but it's
clear the community is divided there).
** Can we make that change? **
Thanks,
-ralph
What is the normal way for userland developers to learn about
constructors? Do they know about LSP? If they do, does it apply to
constructors?
A comment on StackOverflow [1]
At its heart LSP is about interfaces and contracts as well as how to
decided when to extend a class vs. use another strategy such as
composition to achieve your goal.
I am self taught. It was always my understanding that the constructor
was special in that it is, essentially, a magic method that can only
respond to the new keyword. Being able to call the constructor
directly, ..., that does feel a little odd as I can't actually
construct a new instance that way.
Using an interface to enforce the sig is fine. That's the exact nature
of an interface, to enforce the contract by design and if the
StackOverflow comment is accurate, then my understanding of interfaces
is fine with regard to LSP.
An abstract class, by its very nature is not formed. It isn't a
contract. It is an idea and the concrete doesn't need to fit
perfectly. OK. There is some things that are fixed, method signatures
most accept the parameters defined in the subclass but can add more
(as I understand things).
But is the signature of the constructor in an abstract class to be
enforced? I feel that it shouldn't be. It is a special method.
WikiPedia [2] has an article on Constructor Overloading. It says
Constructors, used to create instances of an object, may also be
overloaded in some object oriented programming languages.. OK, so
WikiPedia may have a different opinion tomorrow.
Whilst we don't support overloading in the same way (I think we can
simulate it with __call() easily enough with ReflectionParameter being
my friend here maybe).
We, DO, provide the tools to allow overloading and non LSP coding
practises. Is it a great leap to also allow the same flexibility with
constructors?
Regards,
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 23 November 2011 01:50, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Folks: I just stumbled upon a regression in 5.4. In an array, a sub-sub-key of an existing key is now returning a letter of the value indexed by the main key. I'm raising it here so it doesn't get lost. https://bugs.php.net/bug.php?id=60362 Thanks, --Dan I've just ran the code for the bug through all the V5 releases/betas/alphas/RCs. V5.0.0 to V5.0.2 BEHAVIOR CHANGED: sub-key 'non_existent' is not set. expected: sub-key 1 is set: string(1) o --- good: sub-sub-key 'sub_sub' is not set. good: sub-sub-key 0 is not set. --- BEHAVIOR CHANGED: sub-key 'non_existent' is empty. expected: sub-key 1 is NOT empty: string(1) o --- good: sub-sub-key 'sub_sub' is empty. good: sub-sub-key 0 is empty. V5.0.3 (don't have) V5.0.4 to V5.3.9RC2-dev (as at around 10am GMT on the 23rd Nov 2011). expected: sub-key 'non_existent' is set: string(1) f expected: sub-key 1 is set: string(1) o --- good: sub-sub-key 'sub_sub' is not set. good: sub-sub-key 0 is not set. --- expected: sub-key 'non_existent' is not empty: string(1) f expected: sub-key 1 is NOT empty: string(1) o --- good: sub-sub-key 'sub_sub' is empty. good: sub-sub-key 0 is empty. V5.4+ (betas and RCs) expected: sub-key 'non_existent' is set: string(1) f expected: sub-key 1 is set: string(1) o --- BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) f BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) o --- expected: sub-key 'non_existent' is not empty: string(1) f expected: sub-key 1 is NOT empty: string(1) o --- BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) f BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) o So there was a previous bug fix in V5.0.2 (maybe 5.0.3). So, the whole type juggling point here is mute. It has been that way for a very long time. I just didn't realise it. And if that is a valid result (var_dump($arr['exists']['non_existent']) === 'f') - which it now is obviously is, then the change in V5.4 is certainly a bug fix. But, it is a significant enough issue that warrants a decent amount of documentation. -- Richard Quadling Twitter : EE : Zend : PHPDoc : Fantasy Shopper @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea : fan.sh/6/370 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Thanks Ferenc Everything looks ok http://codepad.viper-7.com/JTXsGK Devis On 24 November 2011 10:31, Ferenc Kovacs tyr...@gmail.com wrote: It gives me false in 5.3.6. Using it outside of isset() results in the fatal error. hm. tyrael@thor:~$ php -r '$string = foo;isset($string[foo][bar][baz][0]);'; PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 tyrael@thor:~$ php -v PHP 5.3.8-1~dotdeb.2 with Suhosin-Patch (cli) (built: Aug 25 2011 13:30:46) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH I will check this against a vanilla version, as there is a chance that either dotdeb(less likely) or suhosin patched something. I just remembered that there is http://codepad.viper-7.com/ so: 5.3 - fatal error: http://codepad.viper-7.com/GGhoSn 5.4 - works: http://codepad.viper-7.com/WRdyni -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 2:04 PM, de...@lucato.it wrote:
Thanks Ferenc
Everything looks ok http://codepad.viper-7.com/JTXsGK
Devis
here are the corner cases:
5.3: http://codepad.viper-7.com/nPLorU
5.4: http://codepad.viper-7.com/MUdAlc
as you can see from the 4th example, your test will have an unexpected
result, if your $widget_options['dashboard_incoming_links'] is a string,
instead of an array, and it's first character is the same as
your get_option('home') return value.
this is because for string offsets the engine does a type juggling to int
for the index.
which is new in 5.4, that string offset chaining is supported, so as you
can see in the 5th example, your check will also fail if $widget_options is
a string instead of an array, and it's first character is the same as
your get_option('home') return value.
(this won't happen if your expected to be array variable is an empty
string, because isset($empty_string[0]) is false.)
another thing that I noticed while playing around:
in 5.3 the following code works:
$foobar = 'foobar';
isset($foobar['foo']);
isset($foobar['foo']['bar']);
echo $foobar['foo'];
but the following will trigger the fatal error:
isset($foobar['foo']['bar']['baz']);
echo $foobar['foo']['bar'];
So isset in 5.3 isn't immune to the fatal error, just it needs one more
chain to trigger it.
Which means that it is less likely to bump into this bug than I thought.
$string = 'foobar';
var_dump(isset($string['foo'])); // this behaves the same, both 5.3 and 5.4
returns true
var_dump($string['foo']); // this behaves the same, both 5.3 and 5.4
returns $string[0] - 'f'
var_dump(isset($string['foo']['bar'])); // this behaves differently, 5.3
returns false but 5.4 returns true
var_dump($string['foo']['bar']); // this behaves differently, 5.3 fatals
but 5.4 returns $string[0] - 'f'
5.3:
http://codepad.viper-7.com/yLajg6
5.4:
http://codepad.viper-7.com/S8Q7DG
Additional chaining will produce fatal errors in 5.3 (both for accessing
and calling isset) and will work in 5.4.
So there are only 2 cases, where 5.4 is different from 5.3, and the one of
them was throwing fatal error in 5.3, and I think that making it work
wouldn't count as a BC break.
Which means that there is only one single case which changes existing
behavior(breaks BC) and that is isset($string['foo']['bar']) the exact same
case that Daniel reported.
Another thing:
In 5.4 accessing arrays and strings through indexes/offsets have some
inconsistencies:
- isset($array[0][0][0][0]..[0]) will always return true for strings, but
that's not true for arrays.
- $array[0][0][0][0]..[0] will produce a notice for arrays(undefined
index), but that's not true for strings.
This is of course because they are different things, I'm just stating there
for the sake of completeness.
So I think if we could lessen/negate the impact of that single case, this
change wouldn't have BC issues.
ps:
I think that we can all agree that $foo[1][0] makes sense if $foo is an
array, but it isn't really useful if $foo is a string (as it will return
the same character as $foo[1][0]).
The other improvement (related but not introduced in this change) that I
suggested was that we could also trigger a notice when a non-applicable
string offset is passed(defining non-applicable is a little bit hard,
because of the current type-juggling rules, we have to allow $string[1],
because '1 can come from a database, or get/post, where it would be a
string, not an int, but if we go with the current type juggling,
$string[2_foo_3] would also be converted to $string[2], which isn't
really intended imo. .
Sorry for the long mail.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] intl IDNA patch
I've committed support for UTS #46 to 5.4 and trunk. See http://svn.php.net/viewvc?view=revisionrevision=319770 -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl IDNA patch
hi Gustavo! Thanks! can you add a note to UPGRADING and in the bug report please? Cheers, On Thu, Nov 24, 2011 at 6:58 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: I've committed support for UTS #46 to 5.4 and trunk. See http://svn.php.net/viewvc?view=revisionrevision=319770 -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/23/2011 12:13 PM, Lester Caine wrote: Richard Quadling wrote: I agree with Daniel on this. Just looking for any test relating to isset() to see what tests will now fail. So it's not just me :) I am seeing this break real world projects and can't see a easy way to fix the break. There is nothing really wrong with the current code except that the sub keys have yet to be populated. This is going to be a huge problem for Drupal. Drupal uses deep associative array structures a lot, by design. That means we isset() or empty() on arrays a lot. I haven't had a chance to test it yet, but I see this change breaking, um, A LOT. And as Daniel noted, the fix is to turn one line of very readable code into 8 lines of hard to read code. This is not a step forward by any metric I can imagine. It's changing long-standing behavior for no real benefit I can see except perhaps strict adherence to a doc page. However, PHP has always been an implementation is the standard language, which means this is a language API change. Please roll it back to avoid breaking a crapton of existing, legitimate, non-buggy code. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/24/2011 12:12 PM, Larry Garfield wrote: On 11/23/2011 12:13 PM, Lester Caine wrote: Richard Quadling wrote: I agree with Daniel on this. Just looking for any test relating to isset() to see what tests will now fail. So it's not just me :) I am seeing this break real world projects and can't see a easy way to fix the break. There is nothing really wrong with the current code except that the sub keys have yet to be populated. This is going to be a huge problem for Drupal. Drupal uses deep associative array structures a lot, by design. That means we isset() or empty() on arrays a lot. I haven't had a chance to test it yet, but I see this change breaking, um, A LOT. And as Daniel noted, the fix is to turn one line of very readable code into 8 lines of hard to read code. This is not a step forward by any metric I can imagine. It's changing long-standing behavior for no real benefit I can see except perhaps strict adherence to a doc page. However, PHP has always been an implementation is the standard language, which means this is a language API change. Please roll it back to avoid breaking a crapton of existing, legitimate, non-buggy code. I had a quick look through the Drupal code. I don't see a single place that this is done where a deeply nested array index is applied to a string. I think you are misunderstanding what has changed here. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.9RC2 and PHP 5.4.0RC2 released
Hello, The PHP team released the second release candidates of PHP 5.3.9 and PHP 5.4.0 today: You can find the packages for PHP 5.3.9RC2 here: http://downloads.php.net/johannes and respectively for PHP 5.4.0RC2: http://downloads.php.net/stas The Windows team provides windows binaries for both releases which you find here: http://windows.php.net/qa/ Please ensure that the releases are solid and all things behave as expected! Test these release candidates against your code base and report any problems you encounter or successful tests you've run. The third release candidates will be released on December 8. regards, Johannes, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts On Implementing Decorator Sugar to core
On 11/23/2011 09:24 AM, Anthony Ferrara wrote:
*snip*
Now, with traits we could add a trait for each interface which proxies
back to `$this-object`. But that's still a lot of duplication and
hard-coding.
I've run into this issue before myself. It's especially a problem when
you're specifying a parameter type, because that means you can't just
use __call().
It's also a problem then when you are stacking decorators.
class A implements Foo {
// a dozen methods from Foo
}
class B implements Foo {
// A dozen methods from Foo, all of which just call $this-a-X();
public function newStuff() {}
}
class C implements Foo {
// A dozen methods from Foo, all of which just call $this-a-X();
}
$c = new C(new B(new A)));
$c-newStuff(); // Fail, unless you use __call(), in which case you
can't type hint on B.
So, I've been trying to think of a few methods to add syntactic sugar
to PHP to make this a lot easier. So here's my thoughts
Option 1
Add a magic interface `\PHP\Decorator` which would declare a
`getDecoratedObject()` method. It would after construction call that
method to figure out what interfaces the decorated object uses. Then,
it would magically implement them (as above) on the class if they
weren't already implemented (overridden). That way the decorated
object could be resolved at runtime. I'm not sold on this concept as
it feels a bit too magic to me.
class MyDecorator implements \PHP\Decorator {
protected $object;
public function __construct($object) {
$this-object = $object;
}
public function getDecoratedObject() {
return $this-object;
}
public function addedFunctionality() {
// blah
}
}
I don't see this as too much magic; it's really no more magical than the
Countable or Iteratable interfaces. Funky cool language functionality
triggered by an interface. The advantage here is that it would give
you lots of flexibility as to what the object to decorate is; it could
be one passed in, or one instantiated internally, or one extracted from
an object that's passed in, etc. It would require documenting precisely
when getDecoratedObject() is called. I'd recommend that it get called
right after the constructor finishes.
Alternatively, could it be an internal-only setter? Call
-setDecoratedObject() somewhere within the class and that's the object
that gets magically passed through to. Not sure if that works with an
interface, though, since we wouldn't want that to be public.
Option 2
Implement a magic interface `\PHP\Decorator` which would then allow
all declared interfaces to be satisfied by `__call`. This should
require the least change to the core, since the only real change
that's needed is in the core where it checks that the declared
interface is satisfied.
class MyDecorator implements IteratorAggregate, Countable {
protected $object = null;
public function __construct($object) {
$this-object = $object;
}
public function __call($name, $args) {
return call_user_func_array(array($this-object, $name), $args);
}
public function addedFunctionality() {
// blah
}
}
I don't like this approach. One, it basically says if I put this
interface on my class, disable type checking. That defeats the
purpose. It also has the problem that you can then only decorate one
object (as noted in option 3). Also, stacking __call() and
call_user_func_array() is one of the slowest things you can do in the
language, in my testing, as well as making life much more difficult for
people trying to debug code.
Option 3
Add syntax to the member declaration that lets you declare which
methods should be proxied to a member object. So something like this:
class MyDecorator implements IteratorAggregate, Countable {
protected $object decorates {
public function getIterator();
public function count();
}
public function __construct($object) {
$this-object = $object;
}
public function addedFunctionality() {
// blah
}
}
Then, at compile time the core could do a replace on the class to add
the proxy methods. This has a major advantage in that you could use
multiple classes to selectively satisfy an interface. So you could
actually use it to compose an object at compile time that proxies to
multiple objects.
I like the flexibility here. It also seems consistent with the trait
syntax, I think. My only question is if we'd want to allow a short-hand
to say that $object satisfies all methods on a given interface. If your
interface has a dozen methods, that's still a dozen lines of code you
would need (and need to update if the interface ever changes). So maybe:
class MyDecorator implements IteratorAggregate, Countable {
protected $object decorates IteratorAggregate, {
public function count();
}
}
(Or something.)
Personally, I like the explicitness of Option 3,
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 9:12 PM, Larry Garfield la...@garfieldtech.comwrote:
On 11/23/2011 12:13 PM, Lester Caine wrote:
Richard Quadling wrote:
I agree with Daniel on this.
Just looking for any test relating to isset() to see what tests will
now fail.
So it's not just me :)
I am seeing this break real world projects and can't see a easy way to
fix the break. There is nothing really wrong with the current code
except that the sub keys have yet to be populated.
This is going to be a huge problem for Drupal. Drupal uses deep
associative array structures a lot, by design. That means we isset() or
empty() on arrays a lot. I haven't had a chance to test it yet, but I see
this change breaking, um, A LOT. And as Daniel noted, the fix is to turn
one line of very readable code into 8 lines of hard to read code.
Did you managed to read the whole thread?
I'm asking because there were lot of confusion about the actual impact of
this problem, and Lester particularly seemed confused.
There is nothing really wrong with the current code except that the sub
keys have yet to be populated.
that isn't true, if the array or some sub elements are empty(yet to be
populated), you won't bump into this change. See my previous mail for the
exact details.
so the above mentioned one liner:
if (isset($arr['package']['attribs']['version'])) {
what could go wrong:
$arr is not an array, but a string - it would fatal on 5.3(Fatal: cannot
use string offset as an array), but it would work with 5.4
$arr['package'] is not an array but a string - false on 5.3, true on 5.4
(this is the worst case)
$arr['package']['attribs'] is not an array but a string - true on both 5.3
and 5.4 (so you are already screwed)
the least amount of change to fix that isset would be:
isset($arr[package][attribs]) is_array($arr[package][attribs])
isset($arr[package][attribs][version]);
a little bit bit longer, right.
I think that if you can't guarantee your data, then you have to
check/sanitize it.
isset($array['foo']['bar']['baz']) could seem as a good idea, but don't
forget that if $array or one of it's element will be, for example an
object(not implementing ArrayAccess) then your isset will still fail with a
fatal error:
$arr = new StdClass;
isset($arr[package][attribs][version]);
PHP Fatal error: Cannot use object of type stdClass as array
This is not a step forward by any metric I can imagine. It's changing
long-standing behavior for no real benefit I can see except perhaps strict
adherence to a doc page. However, PHP has always been an implementation
is the standard language, which means this is a language API change.
Stas and Etienne explained in this thread what was the reason introducing
this change(removing the string offset pseudo-type).
Please roll it back to avoid breaking a crapton of existing, legitimate,
non-buggy code.
This change would only break buggy code, where a string is checked as it
would be an array, and I would also argue about the crapton part.
As I mentioned before, if your input validation is so fragile, that you can
be bitten by this bug, then most probably you can also be bitten by the
same problem which exists in 5.3( see $arr['package']['attribs'] is not an
array but a string).
The only real-world example where this breaks something was a test in the
PEAR codebase, albeit Daniel didn't mentioned the test, I have a feeling
that if we check it, we will see that the test itself is buggy (else it
couldn't have triggered this thread).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi! This is going to be a huge problem for Drupal. Drupal uses deep associative array structures a lot, by design. That means we isset() or empty() on arrays a lot. I haven't had a chance to test it yet, but I see this change breaking, um, A LOT. And as Daniel noted, the fix is to turn one line of very readable code into 8 lines of hard to read code. Well, I do not think we're going to break the engine in a way that will act as it acted in 5.3 - to introduce new pseudo-type that works with $a[0] but not with $a[0][0] and bring in all the old bugs, even if Drupal relies on some side effect of them. I am not a Drupal developer so I have no idea why Drupal would use side effects of string offset bugs to distinguish between arrays and strings, but this is a wrong decision and needs to be changed, since among other things it means that code like isset($foo[0][0]) and $bar=$foo[0]; isset($bar[0]); works differently, which makes no sense. So the question is - what can be done that works with 5.4 engine and is consistent, but will be better for Drupal and others that made similar mistakes of relying on a bug in pre-5.4 implementation of string offsets? Please roll it back to avoid breaking a crapton of existing, legitimate, non-buggy code. Again, there's no rolling back this change, unless you want to throw out all 5.4 improvements in the engine, on which stage we might as well throw out whole 5.4 thing and forget about improving PHP, since it may disrupt somebody's code that relies precisely on the bugs being fixed. Sorry for being dramatic, but I've repeated it three times already so I'd really want for it to sink in this time - this change is an integral part of 5.4 engine cleanup and it can not be changed without seriously breaking the engine - because the way string offsets work now is the right way for them to work (or at least light years more right that what happened in 5.3). So unless somebody comes with a patch that proves me wrong and shows me how old broken way of doing string offsets can be preserved without messing up a lot of things in the engine - there's not rolling back and no reverting, there's nothing to roll back and revert. If, however, anybody has any practical solution to it that improves things - he's more than welcome to come up with the patch and discuss it. I'll think about it too, but since I have no idea what Drupal does I'm not sure if the direction I choose would be best. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
hi Rasmus, On Thu, Nov 24, 2011 at 9:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: I had a quick look through the Drupal code. I don't see a single place that this is done where a deeply nested array index is applied to a string. I think you are misunderstanding what has changed here. We are leading to yet another underestimated impact to userland code, for zero gain. The risk is to high, let revert that please. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/24/2011 01:08 PM, Pierre Joye wrote: hi Rasmus, On Thu, Nov 24, 2011 at 9:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: I had a quick look through the Drupal code. I don't see a single place that this is done where a deeply nested array index is applied to a string. I think you are misunderstanding what has changed here. We are leading to yet another underestimated impact to userland code, for zero gain. The risk is to high, let revert that please. For all the people saying, Revert. You guys realize that also means we revert all the array dereferencing we added elsewhere, right? That includes function array dereferencing which pretty most everyone has been clamoring for for years. So just to clarify, you think we should remove function array dereferencing? Otherwise, please provide a proposal for how we separate these various derefencing mechanisms in a way that doesn't completely destroy the clean and consistent implementation we have right now. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Ferenc Kovacs wrote: Did you managed to read the whole thread? I'm asking because there were lot of confusion about the actual impact of this problem, and Lester particularly seemed confused. There is nothing really wrong with the current code except that the sub keys have yet to be populated. that isn't true, if the array or some sub elements are empty(yet to be populated), you won't bump into this change. See my previous mail for the exact details. My genealogical data site is not working on PHP5.4 ... the arrays of information are not being populated ... WHEN I get some time I will go through things with a fine tooth comb, but for the time being 5.4 is unusable for that site. The same phpgedview code is used by many sites, and while it may simply be my port to Firebird that has the problem, I suspect other sites will be affected. I've tested PHP5.4 ... and it does not work for me ... in much the same way 5.3 didn't and needed a lot of work to get things ported over. Looks to me like EXACTLY the same agro for many users this time as well :( All right the code may be at fault, but much of it originated in PHP4 days and tracking these sorts of black holes is not simple ... otherwise I would know why my site does not work now! Other people have flagged a problem, although it would seem that showing where the problems are is not being followed up, so can people sign off on this change that it will NOT affect production sites? More important if it does affect a site how does one find the problem code? If it worked but gave warnings that would at least be a little better ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi! For all the people saying, Revert. You guys realize that also means we revert all the array dereferencing we added elsewhere, right? That includes function array dereferencing which pretty most everyone has been clamoring for for years. I think you're underestimating it. We'd have to revert many of changes done to the engine in 5.4, and I strongly suspect str_offset is incompatible with literals improvement, which means all performance gains in 5.4 would be ruined too. Pretty much we'd have to roll back whole Zend engine to 5.3 state as far as I can see it. I don't think this even worth discussing. That, of course, does not preclude discussing how we can improve current situation - but by now I would ask anybody who wants to comment about reverting please not to do so because it's going nowhere. If you have a proposal on how to make it better with regard to existing code that relied on sting offsets bugs - you are more than welcome, especially if you propose a patch :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi,
2011/11/24 Richard Quadling rquadl...@gmail.com:
On 23 November 2011 01:50, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Folks:
I just stumbled upon a regression in 5.4. In an array, a sub-sub-key of
an existing key is now returning a letter of the value indexed by the
main key. I'm raising it here so it doesn't get lost.
https://bugs.php.net/bug.php?id=60362
Thanks,
--Dan
I've just ran the code for the bug through all the V5
releases/betas/alphas/RCs.
V5.0.0 to V5.0.2
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) o
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) o
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
V5.0.3 (don't have)
V5.0.4 to V5.3.9RC2-dev (as at around 10am GMT on the 23rd Nov 2011).
expected: sub-key 'non_existent' is set: string(1) f
expected: sub-key 1 is set: string(1) o
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) f
expected: sub-key 1 is NOT empty: string(1) o
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
V5.4+ (betas and RCs)
expected: sub-key 'non_existent' is set: string(1) f
expected: sub-key 1 is set: string(1) o
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) f
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) o
---
expected: sub-key 'non_existent' is not empty: string(1) f
expected: sub-key 1 is NOT empty: string(1) o
---
BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) f
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) o
So there was a previous bug fix in V5.0.2 (maybe 5.0.3).
So, the whole type juggling point here is mute. It has been that way
for a very long time. I just didn't realise it.
And if that is a valid result
(var_dump($arr['exists']['non_existent']) === 'f') - which it now is
obviously is, then the change in V5.4 is certainly a bug fix.
But, it is a significant enough issue that warrants a decent amount of
documentation.
Nice effort for checking PHP 5.0.
I guess this difference comes from string offset access method change
introduced some where in 5.x.
Wasn't it supposed to access string offset like
?php
$str = 'abc';
$c = $str{1};
var_dump($c);
Output from PHP 5.3
string(1) b
Accessing via [] is more consistent, so I prefer current method.
Howerver, following code executes with PHP 5.4
$ ./php -r '$s = abc; var_dump($s[0][bar]);
string(1) a
This is not right behavior. As far as I know, PHP only treat string
index as integer index if and only if string was consisted only by
numbers.
I think current code is using convert_to_long() for sub array. It
should use string index to integer conversion code rather than
convert_to_long() to make consistent behavior.
With PHP 5.3, it rases fatal error
$ php -r '$s = abc; var_dump($s[0][bar]);'
PHP Fatal error: Cannot use string offset as an array in Command line
code on line 1
Raising notice error for accessing string by string offset seems to
be the feasible solution.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi, 2011/11/24 Rasmus Lerdorf ras...@lerdorf.com: On 11/24/2011 01:08 PM, Pierre Joye wrote: hi Rasmus, On Thu, Nov 24, 2011 at 9:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: I had a quick look through the Drupal code. I don't see a single place that this is done where a deeply nested array index is applied to a string. I think you are misunderstanding what has changed here. We are leading to yet another underestimated impact to userland code, for zero gain. The risk is to high, let revert that please. For all the people saying, Revert. You guys realize that also means we revert all the array dereferencing we added elsewhere, right? That includes function array dereferencing which pretty most everyone has been clamoring for for years. So just to clarify, you think we should remove function array dereferencing? Otherwise, please provide a proposal for how we separate these various derefencing mechanisms in a way that doesn't completely destroy the clean and consistent implementation we have right now. -Rasmus The function array dereferencing is unrelated to these changes (it just touched the parser), i.e. it uses the same code used to access the array directly. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl IDNA patch
Hi! I've committed support for UTS #46 to 5.4 and trunk. See http://svn.php.net/viewvc?view=revisionrevision=319770 Could you please also fix the protos on the functions? And updating the docs would be ideal :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi all, I should think twice before seding mail. abc as array index is converted to 0 since it's not a integer. So with current code is behave consistently with regards to string to long conversion. However, PHP 5.3 php -r '$s = abc; var_dump($s[0][bar]);' PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 PHP 5.4 ./php -r '$s = abc; var_dump($s[0][bar]);' string(1) a Isn't it better to raise notice for accessing string by string index? There is no use to allowing string index access to strings. I think raising notice is feasible. Isn't it? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/24/2011 01:44 PM, Yasuo Ohgaki wrote: Hi all, I should think twice before seding mail. abc as array index is converted to 0 since it's not a integer. So with current code is behave consistently with regards to string to long conversion. However, PHP 5.3 php -r '$s = abc; var_dump($s[0][bar]);' PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 PHP 5.4 ./php -r '$s = abc; var_dump($s[0][bar]);' string(1) a Isn't it better to raise notice for accessing string by string index? There is no use to allowing string index access to strings. I think raising notice is feasible. Isn't it? String index access is still required since they are often numeric strings. We could add a notice for non-numeric strings, but the check would slow things down a bit. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 10:44 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I should think twice before seding mail. abc as array index is converted to 0 since it's not a integer. So with current code is behave consistently with regards to string to long conversion. However, PHP 5.3 php -r '$s = abc; var_dump($s[0][bar]);' PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 PHP 5.4 ./php -r '$s = abc; var_dump($s[0][bar]);' string(1) a Isn't it better to raise notice for accessing string by string index? There is no use to allowing string index access to strings. I think raising notice is feasible. Isn't it? agree, and I also suggested adding this notice. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 10:48 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 11/24/2011 01:44 PM, Yasuo Ohgaki wrote: Hi all, I should think twice before seding mail. abc as array index is converted to 0 since it's not a integer. So with current code is behave consistently with regards to string to long conversion. However, PHP 5.3 php -r '$s = abc; var_dump($s[0][bar]);' PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 PHP 5.4 ./php -r '$s = abc; var_dump($s[0][bar]);' string(1) a Isn't it better to raise notice for accessing string by string index? There is no use to allowing string index access to strings. I think raising notice is feasible. Isn't it? String index access is still required since they are often numeric strings. We could add a notice for non-numeric strings, but the check would slow things down a bit. yeah, as I mentioned before: The other improvement (related but not introduced in this change) that I suggested was that we could also trigger a notice when a non-applicable string offset is passed(defining non-applicable is a little bit hard, because of the current type-juggling rules, we have to allow $string[1], because '1 can come from a database, or get/post, where it would be a string, not an int, but if we go with the current type juggling, $string[2_foo_3] would also be converted to $string[2], which isn't really intended imo. . I would vote for allowing only numbers in the string index/offset: [0-9]+ -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
2011/11/25 Rasmus Lerdorf ras...@lerdorf.com: On 11/24/2011 01:44 PM, Yasuo Ohgaki wrote: Hi all, I should think twice before seding mail. abc as array index is converted to 0 since it's not a integer. So with current code is behave consistently with regards to string to long conversion. However, PHP 5.3 php -r '$s = abc; var_dump($s[0][bar]);' PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 PHP 5.4 ./php -r '$s = abc; var_dump($s[0][bar]);' string(1) a Isn't it better to raise notice for accessing string by string index? There is no use to allowing string index access to strings. I think raising notice is feasible. Isn't it? String index access is still required since they are often numeric strings. We could add a notice for non-numeric strings, but the check would slow things down a bit. How about enable notice only for PHP 5.4? Programmer should check vars to see if it's an array, but finding the cause of misbehavior without errors is pain for users. I don't think we have to remove this feature, but it would be nice to raise notice error for a while. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Isn't it better to raise notice for accessing string by string index? There is no use to allowing string index access to strings. I think raising notice is feasible. Isn't it? String index access is still required since they are often numeric strings. We could add a notice for non-numeric strings, but the check would slow things down a bit. yeah, as I mentioned before: The other improvement (related but not introduced in this change) that I suggested was that we could also trigger a notice when a non-applicable string offset is passed(defining non-applicable is a little bit hard, because of the current type-juggling rules, we have to allow $string[1], because '1 can come from a database, or get/post, where it would be a string, not an int, but if we go with the current type juggling, $string[2_foo_3] would also be converted to $string[2], which isn't really intended imo. . I would vote for allowing only numbers in the string index/offset: [0-9]+ By allowing I meant that we should trigger the notice if the string index contains anything else than numbers. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/24/2011 02:58 PM, Ferenc Kovacs wrote:
On Thu, Nov 24, 2011 at 9:12 PM, Larry Garfieldla...@garfieldtech.comwrote:
On 11/23/2011 12:13 PM, Lester Caine wrote:
Richard Quadling wrote:
I agree with Daniel on this.
Just looking for any test relating to isset() to see what tests will
now fail.
So it's not just me :)
I am seeing this break real world projects and can't see a easy way to
fix the break. There is nothing really wrong with the current code
except that the sub keys have yet to be populated.
This is going to be a huge problem for Drupal. Drupal uses deep
associative array structures a lot, by design. That means we isset() or
empty() on arrays a lot. I haven't had a chance to test it yet, but I see
this change breaking, um, A LOT. And as Daniel noted, the fix is to turn
one line of very readable code into 8 lines of hard to read code.
Did you managed to read the whole thread?
I'm asking because there were lot of confusion about the actual impact of
this problem, and Lester particularly seemed confused.
To be fair, no, I hadn't read the whole thread by the time I sent that.
(One of the challenges of long fast-moving threads is they're hard to
keep up with.)
There is nothing really wrong with the current code except that the sub
keys have yet to be populated.
that isn't true, if the array or some sub elements are empty(yet to be
populated), you won't bump into this change. See my previous mail for the
exact details.
so the above mentioned one liner:
if (isset($arr['package']['attribs']['version'])) {
what could go wrong:
$arr is not an array, but a string - it would fatal on 5.3(Fatal: cannot
use string offset as an array), but it would work with 5.4
$arr['package'] is not an array but a string - false on 5.3, true on 5.4
(this is the worst case)
$arr['package']['attribs'] is not an array but a string - true on both 5.3
and 5.4 (so you are already screwed)
So to clarify, what Drupal does on a regular basis is something like:
if (isset($foo['bar']['baz']['beep'])) {
// Assume that bar, baz, and beep all exist, and that beep has a value
}
// or sometimes
if (!empty($foo['bar']['baz']['beep'])) {
// Assume that bar, baz, and beep all exist,
// and that beep has a meaningful value
}
Generally $foo, bar, and baz will all be arrays, and if they're not it
means someone else had a bug somewhere. Of course, Drupal module
developers never have bugs in their code that accidentally puts a string
where they should have put an array, no, not at all. :-) (Generally
when that happens we already hit a first argument to foreach() must be
an array error.)
Currently we don't use ArrayAccess anywhere aside from inheriting it
from PDO.
If that doesn't change, then I rescind my previous panic attack.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 11/24/2011 02:03 PM, Larry Garfield wrote: Generally $foo, bar, and baz will all be arrays, and if they're not it means someone else had a bug somewhere. Of course, Drupal module developers never have bugs in their code that accidentally puts a string where they should have put an array, no, not at all. :-) (Generally when that happens we already hit a first argument to foreach() must be an array error.) Currently we don't use ArrayAccess anywhere aside from inheriting it from PDO. If that doesn't change, then I rescind my previous panic attack. Yes, no change in any of that. In your usage, the case that behaves differently in 5.4 was actually a fatal error in 5.3, so chances are pretty good you don't have too many of these. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, Nov 24, 2011 at 11:03 PM, Larry Garfield la...@garfieldtech.comwrote:
On 11/24/2011 02:58 PM, Ferenc Kovacs wrote:
On Thu, Nov 24, 2011 at 9:12 PM, Larry
Garfieldlarry@garfieldtech.**comla...@garfieldtech.com
wrote:
On 11/23/2011 12:13 PM, Lester Caine wrote:
Richard Quadling wrote:
I agree with Daniel on this.
Just looking for any test relating to isset() to see what tests will
now fail.
So it's not just me :)
I am seeing this break real world projects and can't see a easy way to
fix the break. There is nothing really wrong with the current code
except that the sub keys have yet to be populated.
This is going to be a huge problem for Drupal. Drupal uses deep
associative array structures a lot, by design. That means we isset() or
empty() on arrays a lot. I haven't had a chance to test it yet, but I
see
this change breaking, um, A LOT. And as Daniel noted, the fix is to turn
one line of very readable code into 8 lines of hard to read code.
Did you managed to read the whole thread?
I'm asking because there were lot of confusion about the actual impact of
this problem, and Lester particularly seemed confused.
To be fair, no, I hadn't read the whole thread by the time I sent that.
(One of the challenges of long fast-moving threads is they're hard to keep
up with.)
There is nothing really wrong with the current code except that the sub
keys have yet to be populated.
that isn't true, if the array or some sub elements are empty(yet to be
populated), you won't bump into this change. See my previous mail for the
exact details.
so the above mentioned one liner:
if (isset($arr['package']['**attribs']['version'])) {
what could go wrong:
$arr is not an array, but a string - it would fatal on 5.3(Fatal: cannot
use string offset as an array), but it would work with 5.4
$arr['package'] is not an array but a string - false on 5.3, true on 5.4
(this is the worst case)
$arr['package']['attribs'] is not an array but a string - true on both
5.3
and 5.4 (so you are already screwed)
So to clarify, what Drupal does on a regular basis is something like:
if (isset($foo['bar']['baz']['**beep'])) {
// Assume that bar, baz, and beep all exist, and that beep has a value
}
// or sometimes
if (!empty($foo['bar']['baz']['**beep'])) {
// Assume that bar, baz, and beep all exist,
// and that beep has a meaningful value
}
Generally $foo, bar, and baz will all be arrays, and if they're not it
means someone else had a bug somewhere. Of course, Drupal module
developers never have bugs in their code that accidentally puts a string
where they should have put an array, no, not at all. :-) (Generally when
that happens we already hit a first argument to foreach() must be an
array error.)
if the foreach wouldn't catch this, you would have a chance to run into
this problem (both with 5.3 and 5.4)
Currently we don't use ArrayAccess anywhere aside from inheriting it from
PDO.
I only mentioned ArrayAccess because if an object implements that
interface, then $object['foo'] won't throw an error, but works as it would
be an array.
If that doesn't change, then I rescind my previous panic attack.
I think that bumping into this is less-less-less likely than what the
replies on this thread suggests, and this behavior is already there and
documented, the current change only add another edge-case where you can
trigger it.
The real gotcha is that the string offset index is substituted to the php
style type juggling($string['foo'] is valid and will be interpreted as
$string[0]), and that we use the same syntax for accessing array elements
and string offsets.
The two combined with a wrong/unexpected argument can screw you over, and
we didn't issue a notice on this yet.
It was just a coincidence that by historical reasons the string offset
chaining was disallowed, so there were one corner case, which was prevented
by this.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
[PHP-DEV] [RFC] Autoloader Error Handling
Hi internals, I've written a RFC about the optimization of the autoloader error handling. Please take a moment to review the RFC and post any questions, suggestions or concerns here. https://wiki.php.net/rfc/autoloader_error_handling Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi all, Just FYI find ../php-src-5.3/Zend/ -name *.[ch] | xargs grep -n Cannot use string offset as an array | wc -l111 I thought there are much less lines to raise notice for string offset access, but it isn't. It almost everywhere in vm. Now I understand the reason why Stats and Rusmus cares about decreased performance with notices. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Thu, 24 Nov 2011 22:44:46 -, Yasuo Ohgaki yohg...@ohgaki.net wrote: find ../php-src-5.3/Zend/ -name *.[ch] | xargs grep -n Cannot use string offset as an array | wc -l111 I thought there are much less lines to raise notice for string offset access, but it isn't. It almost everywhere in vm. Now I understand the reason why Stats and Rusmus cares about decreased performance with notices. This is just due to opcode handler specialization. In the source code there are 7 instances in 5.4 and 10 in 5.3. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 24 November 2011 21:48, Rasmus Lerdorf ras...@lerdorf.com wrote: On 11/24/2011 01:44 PM, Yasuo Ohgaki wrote: Hi all, I should think twice before seding mail. abc as array index is converted to 0 since it's not a integer. So with current code is behave consistently with regards to string to long conversion. However, PHP 5.3 php -r '$s = abc; var_dump($s[0][bar]);' PHP Fatal error: Cannot use string offset as an array in Command line code on line 1 PHP 5.4 ./php -r '$s = abc; var_dump($s[0][bar]);' string(1) a Isn't it better to raise notice for accessing string by string index? There is no use to allowing string index access to strings. I think raising notice is feasible. Isn't it? String index access is still required since they are often numeric strings. We could add a notice for non-numeric strings, but the check would slow things down a bit. -Rasmus Would it be possible to have that check only if E_NOTICE is enabled ? That would allow to limit the cost to development environments (assuming one could disable E_NOTICEs on production env). Devis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pg_escape_literal(), pg_escape_identifier() patch
Hi all, I've just committed the patch to trunk. I'll update NEWS file and docs. If anyone notice problem, please let me know. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On Friday, November 25, 2011 08:23 AM, de...@lucato.it wrote:
On 24 November 2011 21:48, Rasmus Lerdorfras...@lerdorf.com wrote:
On 11/24/2011 01:44 PM, Yasuo Ohgaki wrote:
Hi all,
I should think twice before seding mail. abc as array index is
converted to 0 since it's not a integer. So with current code is
behave consistently with regards to string to long conversion.
However,
PHP 5.3
php -r '$s = abc; var_dump($s[0][bar]);'
PHP Fatal error: Cannot use string offset as an array in Command line
code on line 1
PHP 5.4
./php -r '$s = abc; var_dump($s[0][bar]);'
string(1) a
Isn't it better to raise notice for accessing string by string index?
There is no use to allowing string index access to strings. I think
raising notice is feasible. Isn't it?
String index access is still required since they are often numeric
strings. We could add a notice for non-numeric strings, but the check
would slow things down a bit.
-Rasmus
Would it be possible to have that check only if E_NOTICE is enabled ?
That would allow to limit the cost to development environments
(assuming one could disable E_NOTICEs on production env).
Devis
This is a design issue of using the same syntax for arrays and strings,
and accepting string indexes for both, I think this is beginning to
illustrate some of the flaws in that design.
if (isset($_POST['query']['search'])) { This does not do what you
think (if ?query=a_string..
Although the chained string offset fix is probably the right thing to
do, I think it should be reverted in this version, then this process occur:
5.4
- revert chained string offsets
- add E_NOTICE to any usage of string index's of string eg . $a =
string ; $a[string] = gives E_NOTICE
- users can add (int) if they really need to check string indexes of a
string
- isset($string['x']) will return true as present
- isset($string['x']['x']) will return false as present
5.5
- reapply chained string offsets
- add E_FATAL to any usage of string index's of string = eg . $a =
string ; $a[string] = gives E_FATAL
- make $a[string] return an empty string - so isset() on chained
string offsets will work as expected.
- isset($string['x']) will return false as per the warning on the
previous version..
- isset($string['x']['x']) will return false as present
Thoughts.
Regards
Alan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi Ferenc: On Thu, Nov 24, 2011 at 10:54:24PM +0100, Ferenc Kovacs wrote: I would vote for allowing only numbers in the string index/offset: [0-9]+ By allowing I meant that we should trigger the notice if the string index contains anything else than numbers. I agree with this approach as well. Thanks, --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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi Stas: I have no idea why Drupal would use side effects of string offset bugs to distinguish between arrays and strings They're not trying to distinguish between strings and arrays. People using this syntax are trying to see if a particular array element is populated. In the past, it happened to also weed out strings. Now it won't. Thanks, --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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi Rasmus:
Yes, no change in any of that. In your usage, the case that behaves
differently in 5.4 was actually a fatal error in 5.3, so chances are
pretty good you don't have too many of these.
Things only go fatal in 5.3 under some circumstances. Doing isset()
does not:
?php
function test($var) {
echo PHP_VERSION . ' ' . strtoupper(gettype($var)) . \n;
echo one level isset: ;
var_dump(isset($var['blah']));
echo one level is_array: ;
var_dump(is_array($var['blah']));
echo two level isset: ;
var_dump(isset($var['blah']['bloo']));
echo two level is_array: ;
var_dump(is_array($var['blah']['bloo']));
}
test('foo');
?
5.3.9RC3-dev STRING
one level isset: bool(true)
one level is_array: bool(false)
two level isset: bool(false) This is not fatal, the next line is.
two level is_array: PHP Fatal error:
Cannot use string offset as an array...
5.4.0RC3-dev STRING
one level isset: bool(true)
one level is_array: bool(false)
two level isset: bool(true) Was false in 5.3, now is true.
two level is_array: bool(false)
Thanks,
--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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi Anthony:
isset($foo['bar'][1]['baz']) is_array($foo['bar'][1])
You don't need to check each level. Only the one above the key you're
looking at.
Excellent thinking. One hitch... that goes fatal in 5.3 if $foo is a string.
Here's how to write the test so it works the same way under 5.3 and 5.4:
?php
function test2($id, $foo) {
echo ID $id -- ;
var_dump(is_array($foo)
isset($foo['bar'][1]['baz']) is_array($foo['bar'][1]));
// The following goes fatal on test 80.
//var_dump(isset($foo['bar'][1]['baz']) is_array($foo['bar'][1]));
}
test2(10, array('bar' = array(1 = array('baz' = 'string';
test2(20, array('bar' = array(1 = array('boo' = 'string';
test2(30, array('bar' = array(1 = 'string')));
test2(40, array('bar' = array(2 = 'string')));
test2(50, array('boo' = array(1 = 'string')));
test2(60, array('bar' = 'string'));
test2(70, array('boo' = 'string'));
test2(80, 'string');
?
Thanks,
--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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Excellent thinking. One hitch... that goes fatal in 5.3 if $foo is a string.
Here's how to write the test so it works the same way under 5.3 and 5.4:
Correct. However, it's worth noting that it only goes fatal if $foo is a string.
So as long as you know that the root variable is an array, it will
work fine. So perhaps:
is_array($foo) isset($foo['bar'][1]['baz']) is_array($foo['bar'][1])
Where the root is_array may not be necessary if you know it's an array
already (such as in a superglobal or other type-hinted syntax)...
Looking at this deeper, perhaps a notice is indeed the best course of
action. Otherwise it would call code to behave in a non-obvious and
hard to track down way. I know it doesn't immediately see obvious to
me that array('foo') should pass isset($array[0]['bar']['baz'])... I
understand and agree with the change, just the non-obvious nature can
(and likely will) lead to a host of odd bugs. But if it noticed, then
we would at least have an idea where the oddity happened...
Anthony
On Thu, Nov 24, 2011 at 10:07 PM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Anthony:
isset($foo['bar'][1]['baz']) is_array($foo['bar'][1])
You don't need to check each level. Only the one above the key you're
looking at.
?php
function test2($id, $foo) {
echo ID $id -- ;
var_dump(is_array($foo)
isset($foo['bar'][1]['baz']) is_array($foo['bar'][1]));
// The following goes fatal on test 80.
//var_dump(isset($foo['bar'][1]['baz']) is_array($foo['bar'][1]));
}
test2(10, array('bar' = array(1 = array('baz' = 'string';
test2(20, array('bar' = array(1 = array('boo' = 'string';
test2(30, array('bar' = array(1 = 'string')));
test2(40, array('bar' = array(2 = 'string')));
test2(50, array('boo' = array(1 = 'string')));
test2(60, array('bar' = 'string'));
test2(70, array('boo' = 'string'));
test2(80, 'string');
?
Thanks,
--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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pg_escape_literal(), pg_escape_identifier() patch
2011/11/25 Yasuo Ohgaki yohg...@ohgaki.net: Hi all, I've just committed the patch to trunk. I'll update NEWS file and docs. If anyone notice problem, please let me know. NEWS and docs are added. I didn't edit docs for a long time. Current doc system is excellent! -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Autoloader Error Handling
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote: https://wiki.php.net/rfc/autoloader_error_handling Throwing an exception or fatal error in an autoloader absolutely does not make any sense in my eyes. Projects doing this should step back and think a minute about what they dare. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
