Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
May be this overflow checks should be optional? In old ages compilers for Wirth family languages had option to enable or disable overflow checks. If option is enabled we may throw an exception, if no - work as today. Any user would be able to chose between compatibility and safety. Thanks. Dmitry. On Thu, Sep 25, 2014 at 6:43 PM, Rowan Collins wrote: > Andrea Faulds wrote (on 25/09/2014): > >> No bogus value ever gets to a function - it always gets INT_MAX on > >> > overflow. If INT_MAX is harmful for this function, this change does > not > >> > help as you could still pass INT_MAX and this change would not do > anything. > >> > > No it won't. Normally it truncates (module), only some functions cap. > > I saw that in the RFC, and thought it rather odd that a more sane > implementation already exists, but functions have to opt in to use it. > > I thought perhaps it was a side-effect of something else, but > README.PARAMETER_PARSING_API doesn't list any other difference between "l" > and "L": > > > l - long (long) > > L - long, limits out-of-range numbers to LONG_MAX/LONG_MIN (long) > > What was the original motivation for functions to have that choice? > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
Simple majority between second and third options will win, Thanks. Dmitry. On Fri, Sep 26, 2014 at 7:55 AM, Xinchen Hui wrote: > On Fri, Sep 26, 2014 at 11:54 AM, Xinchen Hui wrote: > > Hey: > > > > > > > > On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov wrote: > >> I told it doesn't support strings and objects because it was designed > this > >> way. > >> I don't know who and when did it. > >> > >> It's not complicated to change it in any way. > >> The question which way is better, and it's the reason of voting. > >> > >> I would prefer not to extend list() to support strings, but in case > >> "enabling" would win, I'll make it. > >> > >> Thanks. Dmitry. > >> > >I am working what should we do if none side get 2/3 votes? > worrying > > >it seems it is going there :< > > > > thanks > >> > >> > >> > >> On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev > >> wrote: > >> > >>> Hi! > >>> > >>> > It was on design. list() was intended to support plain arrays only. > >>> > >>> I'm not sure I'm getting this point - why list($a, $b) = $foo is not > >>> just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make > >>> it work that way? > >>> > >>> -- > >>> Stanislav Malyshev, Software Architect > >>> SugarCRM: http://www.sugarcrm.com/ > >>> > > > > > > > > -- > > Xinchen Hui > > @Laruence > > http://www.laruence.com/ > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ >
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On Fri, Sep 26, 2014 at 11:54 AM, Xinchen Hui wrote: > Hey: > > > > On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov wrote: >> I told it doesn't support strings and objects because it was designed this >> way. >> I don't know who and when did it. >> >> It's not complicated to change it in any way. >> The question which way is better, and it's the reason of voting. >> >> I would prefer not to extend list() to support strings, but in case >> "enabling" would win, I'll make it. >> >> Thanks. Dmitry. >> >I am working what should we do if none side get 2/3 votes? worrying >it seems it is going there :< > > thanks >> >> >> >> On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev >> wrote: >> >>> Hi! >>> >>> > It was on design. list() was intended to support plain arrays only. >>> >>> I'm not sure I'm getting this point - why list($a, $b) = $foo is not >>> just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make >>> it work that way? >>> >>> -- >>> Stanislav Malyshev, Software Architect >>> SugarCRM: http://www.sugarcrm.com/ >>> > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
Hey: On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov wrote: > I told it doesn't support strings and objects because it was designed this > way. > I don't know who and when did it. > > It's not complicated to change it in any way. > The question which way is better, and it's the reason of voting. > > I would prefer not to extend list() to support strings, but in case > "enabling" would win, I'll make it. > > Thanks. Dmitry. > I am working what should we do if none side get 2/3 votes? it seems it is going there :< thanks > > > > On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev > wrote: > >> Hi! >> >> > It was on design. list() was intended to support plain arrays only. >> >> I'm not sure I'm getting this point - why list($a, $b) = $foo is not >> just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make >> it work that way? >> >> -- >> Stanislav Malyshev, Software Architect >> SugarCRM: http://www.sugarcrm.com/ >> -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
I told it doesn't support strings and objects because it was designed this way. I don't know who and when did it. It's not complicated to change it in any way. The question which way is better, and it's the reason of voting. I would prefer not to extend list() to support strings, but in case "enabling" would win, I'll make it. Thanks. Dmitry. On Fri, Sep 26, 2014 at 1:50 AM, Stas Malyshev wrote: > Hi! > > > It was on design. list() was intended to support plain arrays only. > > I'm not sure I'm getting this point - why list($a, $b) = $foo is not > just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make > it work that way? > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ >
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On Thu, Sep 25, 2014 at 11:50 PM, Stas Malyshev wrote: > Hi! > > > It was on design. list() was intended to support plain arrays only. > > I'm not sure I'm getting this point - why list($a, $b) = $foo is not > just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make > it work that way? > That's exactly what list() does. The only catch is that $foo here is reused multiple times and mustn't be freed in the meantime (for the cases where $foo is some complex expression resulting in an VAR or TMP_VAR operand). That's what the ZEND_FETCH_ADD_LOCK flags for FETCH_DIM_R does - it does $foo[0] without freeing $foo. However back when list() was introduced FETCH_DIM_R didn't support CONST or TMP_VAR operands, so instead these two used a separate FETCH_DIM_TMP_VAR opcode, which supports only arrays and not strings or objects. Support for CONST|TMP in FETCH_DIM_R was only added in PHP 5.5 as part of constant string/array dereferencing. Long story short, because FETCH_DIM_R now supports CONST and TMP_VAR operands, we can always use it and FETCH_DIM_TMP_VAR can be dropped - that's all that has to be done in order to always support strings and objects in list(). (I've linked a patch for this previously, see https://github.com/nikic/php-src/compare/stringOffsetsInList). If I understood it correctly, then Dmitry's alternative is to add support for CV and VAR operands to FETCH_DIM_TMP_VAR and always use that for list(). This avoids having to check the ZEND_FETCH_ADD_LOCK flag in FETCH_DIM_R. However I don't think that this optimization is related to whether or not we support strings and objects. We can have a separate opcode only for list() in either case, no matter which choice is made here. Nikita
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On 25 September 2014 22:50, Stas Malyshev wrote: > Hi! > >> It was on design. list() was intended to support plain arrays only. > > I'm not sure I'm getting this point - why list($a, $b) = $foo is not > just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make > it work that way? > Why do array_* functions not treat strings as arrays of bytes? If we we can/want to make strings byte arrays, then I am 100% in favour of all array operations working on strings. If this is something we want to work towards for the future, that's great, lets get busy :) - If we want to say "yea list() should work with strings", but no other array functions should work with strings, it seems very odd to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
Hi! > It was on design. list() was intended to support plain arrays only. I'm not sure I'm getting this point - why list($a, $b) = $foo is not just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make it work that way? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 12:45 AM, Nikita Popov wrote:
> On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov
> wrote:
>
>> On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote:
>>
>>> disabling string handling would allow make operation simpler and would
>>> improve regular access to array elements.
>>> We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
>>> in FETCH_DIM_R handler.
>>> However, it's going to be very small improvement, and I don't care a
>>> lot. :)
>>>
>>> enabling string handling would require complication of
>>> ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
>>> It's going to make list() handling a bit slower, but not significantly.
>>>
>>> my choice +1 for disabling.
>>>
>>
>> Could you please clarify why removing string support would make the
>> operation simpler? I voted for always supporting strings because I thought
>> that is the option that simplifies things - in particular it would allow
>> use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R
>> instead. Sample patch here:
>> https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I
>> miss something and we can't do that?
>>
>> Nikita
>>
>
> I'd like to add that the FETCH_DIM_TMP_VAR opcode also provides incorrect
> results if objects are used. list() generally accepts objects implementing
> ArrayAccess, but if the object happens to be a TMP_VAR and
> FETCH_DIM_TMP_VAR is used instead of FETCH_DIM_R, you'll just get a NULL
> result:
>
>
> class Arr implements ArrayAccess {
> private $arr;
> public function offsetGet($k) { return $this->arr[$k]; }
> public function offsetSet($k, $v) { $this->arr[$k] = $v; }
> public function offsetExists($k) { return isset($this->arr[$k]); }
> public function offsetUnset($k) { unset($this->arr[$k]); }
> }
>
> $arr = new Arr;
> $arr[0] = 'foo';
> $arr[1] = 'bar';
>
> list($a, $b) = $arr;
> var_dump($a, $b); // foo, bar
>
> // (object) forces TMP_VAR
> list($a, $b) = (object) $arr;
> var_dump($a, $b); // NULL, NULL
>
> So to handle that case we'd already have to extend the FETCH_DIM_TMP_VAR
> handler to support objects in addition to arrays. At which point I don't
> really see the point of making this a special case and would always use
> FETCH_DIM_R instead (which already has all the necessary code to support
> arrays, objects and strings).
>
> Nikita
>
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
FETCH_DIM_TMP_VAR is used especiualy for list(). It expects array, don't check for objects and strings. It doesn't remove the operand and allow it's reuse in next opcode. FETCH_DIM_R is used for list() only in some cases (when operand IS_VAR). To work in list() context it has to keep operand not destroyed, and to do it FETCH_DIM_R has to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK). Note that this check has to be executed for each array access operation unrelated to list() handling. Thanks. Dmitry. On Fri, Sep 26, 2014 at 12:32 AM, Nikita Popov wrote: > On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote: > >> disabling string handling would allow make operation simpler and would >> improve regular access to array elements. >> We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK) >> in FETCH_DIM_R handler. >> However, it's going to be very small improvement, and I don't care a lot. >> :) >> >> enabling string handling would require complication of >> ZEND_FETCH_DIM_TMP_VAR handler (for strings support). >> It's going to make list() handling a bit slower, but not significantly. >> >> my choice +1 for disabling. >> > > Could you please clarify why removing string support would make the > operation simpler? I voted for always supporting strings because I thought > that is the option that simplifies things - in particular it would allow > use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R > instead. Sample patch here: > https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I > miss something and we can't do that? > > Nikita >
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov wrote:
> On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote:
>
>> disabling string handling would allow make operation simpler and would
>> improve regular access to array elements.
>> We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
>> in FETCH_DIM_R handler.
>> However, it's going to be very small improvement, and I don't care a lot.
>> :)
>>
>> enabling string handling would require complication of
>> ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
>> It's going to make list() handling a bit slower, but not significantly.
>>
>> my choice +1 for disabling.
>>
>
> Could you please clarify why removing string support would make the
> operation simpler? I voted for always supporting strings because I thought
> that is the option that simplifies things - in particular it would allow
> use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R
> instead. Sample patch here:
> https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I
> miss something and we can't do that?
>
> Nikita
>
I'd like to add that the FETCH_DIM_TMP_VAR opcode also provides incorrect
results if objects are used. list() generally accepts objects implementing
ArrayAccess, but if the object happens to be a TMP_VAR and
FETCH_DIM_TMP_VAR is used instead of FETCH_DIM_R, you'll just get a NULL
result:
arr[$k]; }
public function offsetSet($k, $v) { $this->arr[$k] = $v; }
public function offsetExists($k) { return isset($this->arr[$k]); }
public function offsetUnset($k) { unset($this->arr[$k]); }
}
$arr = new Arr;
$arr[0] = 'foo';
$arr[1] = 'bar';
list($a, $b) = $arr;
var_dump($a, $b); // foo, bar
// (object) forces TMP_VAR
list($a, $b) = (object) $arr;
var_dump($a, $b); // NULL, NULL
So to handle that case we'd already have to extend the FETCH_DIM_TMP_VAR
handler to support objects in addition to arrays. At which point I don't
really see the point of making this a special case and would always use
FETCH_DIM_R instead (which already has all the necessary code to support
arrays, objects and strings).
Nikita
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote: > disabling string handling would allow make operation simpler and would > improve regular access to array elements. > We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK) > in FETCH_DIM_R handler. > However, it's going to be very small improvement, and I don't care a lot. > :) > > enabling string handling would require complication of > ZEND_FETCH_DIM_TMP_VAR handler (for strings support). > It's going to make list() handling a bit slower, but not significantly. > > my choice +1 for disabling. > Could you please clarify why removing string support would make the operation simpler? I voted for always supporting strings because I thought that is the option that simplifies things - in particular it would allow use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R instead. Sample patch here: https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I miss something and we can't do that? Nikita
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On 25.09.14 09:42, Dmitry Stogov wrote: > The vote is opened at > https://wiki.php.net/rfc/fix_list_behavior_inconsistency Voted +1 for disabling. I think string handling needs more thorough designing and planning for edge case and such; i.e. the string handling alternative seems to rushed to me thus I err on the cautious side. thank you, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
2014-09-25 9:42 GMT+02:00 Dmitry Stogov : > Hi, > > The vote is opened at > https://wiki.php.net/rfc/fix_list_behavior_inconsistency > > Thanks. Dmitry. > Hi, I'm in favor of disabling for consistency as well, however, I wish a warning would be emitted. Not only it would tell me that I have a potential error while upgrading to PHP 7 but also if I am using it incorrectly, which is always the case when using a scalar value. I therefor propose that: list($a, $b) = 42; list($a, $b) = "42"; list($a, $b) = null; ... generates a warning like: PHP Warning: list() expects right operand to be array, given in on line Currently, all of the above lines wouldn't generate any notice / warning / error, however, using: list($a, $b) = []; generates the following notices: PHP Notice: Undefined offset: 1 in ... on line ... PHP Notice: Undefined offset: 0 in ... on line ... This is confusing since (to me) using an array is at least better than using scalars. Patrick
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
Hi everyone, On 25 Sep 2014, at 17:27, Patrick ALLAERT wrote: [...] > > I'm in favor of disabling for consistency as well, however, I wish a > warning would be emitted. Voted in favour of disabling as well but could easily live with the other option as everything is better then leaving the inconsistency there. cu, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
Andrea Faulds wrote (on 25/09/2014): >> No bogus value ever gets to a function - it always gets INT_MAX on >> > overflow. If INT_MAX is harmful for this function, this change does not >> > help as you could still pass INT_MAX and this change would not do anything. >> > No it won't. Normally it truncates (module), only some functions cap. I saw that in the RFC, and thought it rather odd that a more sane implementation already exists, but functions have to opt in to use it. I thought perhaps it was a side-effect of something else, but README.PARAMETER_PARSING_API doesn't list any other difference between "l" and "L": > l - long (long) > L - long, limits out-of-range numbers to LONG_MAX/LONG_MIN (long) What was the original motivation for functions to have that choice? -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
disabling string handling would allow make operation simpler and would improve regular access to array elements. We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK) in FETCH_DIM_R handler. However, it's going to be very small improvement, and I don't care a lot. :) enabling string handling would require complication of ZEND_FETCH_DIM_TMP_VAR handler (for strings support). It's going to make list() handling a bit slower, but not significantly. my choice +1 for disabling. Thank. Dmitry. On Thu, Sep 25, 2014 at 12:00 PM, Leigh wrote: > On 25 September 2014 08:42, Dmitry Stogov wrote: > > Hi, > > > > The vote is opened at > > https://wiki.php.net/rfc/fix_list_behavior_inconsistency > > > > Thanks. Dmitry. > > Since in the "should people be allowed to vote" thread, I said I think > people should explain their votes, here is my explanation :) > > I am voting disable. +1 for consistency, but I think we already have a > pretty rich suite of functions for working with strings that do not > work with arrays, and vice versa. I think enabling list() to work on > strings sets a precedent that more/all array handling mechanisms > should be made to work with strings, and I'm not sure that's something > we want. > > We've defined list as not working with strings in the manual, lets > stick to our own definition. >
Re: [PHP-DEV] Little switch improvement: get the used variable
Christian Stoller wrote (on 25/09/2014):
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September
25, 2014 12:31 PM
Sorry, I was talking about this bit:
Currently, switch always uses a "loose" comparison (==), so cannot
distinguish between "case 3" and "case 3.0". Occasionally, it would be
nice to switch on a strict comparison (===); but then I thought, why
stop there? What if you could use switch with any comparison operator?
My idea is to give the switch() statement an optional "use" clause
(since that's an existing keyword) containing a single comparison operator
See my earlier e-mail for examples and further details. Maybe I should
have given it its own thread so it was more visible; the idea has been
brewing for a while, I just thought this thread was a convenient place
to mention.
Ah, okay, sorry.
What do you think about that:
$value = 3;
switch (true) {
case 3.0 === $value: break;
case 3 < $value: break;
case 3 > $value: break;
}
Christian
When mixing operators like that, it makes sense to use that style -
although if you're not using fallthrough, there is little advantage over
if/elseif/else:
$value = 3;
if ( 3.0 === $value ) { }
elseif ( case 3 < $value ) { }
elseif ( case 3 > $value ) { }
At the end of the day, all control structures are glorified conditional
jumps, and most switch statements are glorified if/else blocks. To take
one of my examples from last night, you could write:
if ( $product instanceOf ProductInterfaces\Flight ) {
// ...
}
elseif ( $product instanceOf ProductInterfaces\Accomm ) {
// ...
}
else {
// ...
}
Clearly, this works, as would the same thing using switch(true) and case
instead of if/elseif, but the "$product instanceOf" has to be copied
into every clause, and someone reading the code cannot assume that all
the clauses are performing the same test.
In my proposed version, the intent is expressed more clearly, and there
is less risk of a bug being introduced by incorrect copying or refactoring:
switch ( $product ) use ( instanceOf ) {
case ProductInterfaces\Flight:
// ...
break;
case ProductInterfaces\Accomm:
// ...
break;
default:
// ...
}
That's the idea anyway.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi, On Thu, 2014-09-25 at 12:22 +0200, Florian Margaine wrote: > Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here: > https://github.com/krakjoe/php-src/compare/addressof > > I think it makes more sense than a new method on all objects. You could use > it for any kind of value: scalar, resource, object. Building an array of > sockets, for example, would be very easy with such an operator. For one this leaks quite some implementation details to userland which we shouldn't do aside from debugging features. Secondly this becomes unintuitive with value objects (see my DateTime example in this thread) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Le 25 sept. 2014 12:54, "Pierre Joye" a écrit : > > On Thu, Sep 25, 2014 at 12:22 PM, Florian Margaine wrote: > > Hi, > > > > Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here: > > https://github.com/krakjoe/php-src/compare/addressof > > > > I think it makes more sense than a new method on all objects. You could use > > it for any kind of value: scalar, resource, object. Building an array of > > sockets, for example, would be very easy with such an operator. > > > > It would also give better tools to deal with situations such as: > > > > $test = 1; > > $test2 &= $test; > > > > I'm willing to write an RFC if necessary to include it. > > > > Thoughts? > ´ > Not sure what is the relation with resource as objects but I am not > sure either about exposing the internal position to the userland. That > will pretty much forces to keep it this way forever if we expose it > for anything but debugging. The thing is, we already expose it through references, but we don't give any tool to help people debug them. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Thu, Sep 25, 2014 at 12:22 PM, Florian Margaine wrote: > Hi, > > Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here: > https://github.com/krakjoe/php-src/compare/addressof > > I think it makes more sense than a new method on all objects. You could use > it for any kind of value: scalar, resource, object. Building an array of > sockets, for example, would be very easy with such an operator. > > It would also give better tools to deal with situations such as: > > $test = 1; > $test2 &= $test; > > I'm willing to write an RFC if necessary to include it. > > Thoughts? ´ Not sure what is the relation with resource as objects but I am not sure either about exposing the internal position to the userland. That will pretty much forces to keep it this way forever if we expose it for anything but debugging. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Little switch improvement: get the used variable
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September
25, 2014 12:31 PM
>
> Sorry, I was talking about this bit:
>
>> Currently, switch always uses a "loose" comparison (==), so cannot
>> distinguish between "case 3" and "case 3.0". Occasionally, it would be
>> nice to switch on a strict comparison (===); but then I thought, why
>> stop there? What if you could use switch with any comparison operator?
>>
>> My idea is to give the switch() statement an optional "use" clause
>> (since that's an existing keyword) containing a single comparison operator
>
> See my earlier e-mail for examples and further details. Maybe I should
> have given it its own thread so it was more visible; the idea has been
> brewing for a while, I just thought this thread was a convenient place
> to mention.
Ah, okay, sorry.
What do you think about that:
$value = 3;
switch (true) {
case 3.0 === $value: break;
case 3 < $value: break;
case 3 > $value: break;
}
Christian
Re: [PHP-DEV] Little switch improvement: get the used variable
Christian Stoller wrote (on 25/09/2014): Am I missing something equally obvious there? Or just, it doesn't >interest people much as an idea? Why should one add a new operator in that context if it is already possible with assigments as expressions? This makes the language more complex without getting any improvement. Sorry, I was talking about this bit: Currently, switch always uses a "loose" comparison (==), so cannot distinguish between "case 3" and "case 3.0". Occasionally, it would be nice to switch on a strict comparison (===); but then I thought, why stop there? What if you could use switch with any comparison operator? My idea is to give the switch() statement an optional "use" clause (since that's an existing keyword) containing a single comparison operator See my earlier e-mail for examples and further details. Maybe I should have given it its own thread so it was more visible; the idea has been brewing for a while, I just thought this thread was a convenient place to mention. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi, Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here: https://github.com/krakjoe/php-src/compare/addressof I think it makes more sense than a new method on all objects. You could use it for any kind of value: scalar, resource, object. Building an array of sockets, for example, would be very easy with such an operator. It would also give better tools to deal with situations such as: $test = 1; $test2 &= $test; I'm willing to write an RFC if necessary to include it. Thoughts? On Thu, Sep 25, 2014 at 11:50 AM, Pierre Joye wrote: > On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds wrote: > > > > On 24 Sep 2014, at 20:39, Stas Malyshev wrote: > > > >>> I also wonder why we still need them. Doing what has been done with gmp > >>> for all resources would be a good move for 7. > >> > >> In general, I think we do not - IIRC everything resources do objects can > >> do better now, and the problems that prevented one from using objects > >> instead of resources are long gone. > >> > >> However, is_resource() checks and lots of third-party extensions using > >> resources may be a bit of a problem for eliminating them. > > > > I already figured out how to solve the `is_resource()` issue. Create an > almost-useless, uninstantiatable class called Resource which any new > resource-replacing classes inherit from. Then, make `is_resource()` check > whether something is an instance of that class. > > > > Of course, 3rd-party extensions are still a problem, but this should > mostly fix it. Of course, gettype() is still going to return “object” not > “resource”, but I suspect people are more likely to use is_resource(). > > Is it really necessary? I could imagine a transition with 5.7 for > that, similar to gmp. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > -- Regards, *Florian Margaine*
RE: [PHP-DEV] Little switch improvement: get the used variable
Mit freundlichen Grüßen aus Paderborn
Christian Stoller
Softwareentwicklung
LEONEX Internet GmbH
Technologiepark 20
33100 Paderborn
Tel: 05251-14807-27
Fax: 05251-14807-30
HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter
--
APPsolut nützlich - mit Apps neue Geschäftsmodelle & Geschäftsprozesse gestalten
Dienstag, 04. November 2014, mehr unter http://bit.ly/YXDNa3
--
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September
25, 2014 11:10 AM
> Rowan Collins wrote (on 24/09/2014):
>> On 24/09/2014 22:33, Andrea Faulds wrote:
>>> On 24 Sep 2014, at 22:17, Rowan Collins wrote:
>>>
Perhaps rather than a magic function or constant, though, the switch
statement could be extended with an "as" argument, which would store
the evaluated expression into a normal variable, allowing nesting,
and easier optimisation of the engine where the feature isn't used.
Thus you could write this:
switch( some_expression() as $switch_value ){
case 1:
do_something();
break;
//...
default:
throw new Exception('Undefined input: ' . $switch_value);
break;
}
>>> Incredibly, some brave soul has gone back in time and already
>>> implemented this, when none of us was looking!
>>>
>>> switch($switch_value = some_expression()) {
>>> ...
>>> }
>>>
>>
>> Heh, now I feel like a fool for not thinking of that.
>>
>> Treating assigments as expressions just isn't something that jumps to
>> mind, I guess!
>>
>
> Anyone have any thoughts on the use(operator) part, though?
>
> Am I missing something equally obvious there? Or just, it doesn't
> interest people much as an idea?
Why should one add a new operator in that context if it is already
possible with assigments as expressions?
This makes the language more complex without getting any improvement.
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds wrote: > > On 24 Sep 2014, at 20:39, Stas Malyshev wrote: > >>> I also wonder why we still need them. Doing what has been done with gmp >>> for all resources would be a good move for 7. >> >> In general, I think we do not - IIRC everything resources do objects can >> do better now, and the problems that prevented one from using objects >> instead of resources are long gone. >> >> However, is_resource() checks and lots of third-party extensions using >> resources may be a bit of a problem for eliminating them. > > I already figured out how to solve the `is_resource()` issue. Create an > almost-useless, uninstantiatable class called Resource which any new > resource-replacing classes inherit from. Then, make `is_resource()` check > whether something is an instance of that class. > > Of course, 3rd-party extensions are still a problem, but this should mostly > fix it. Of course, gettype() is still going to return “object” not > “resource”, but I suspect people are more likely to use is_resource(). Is it really necessary? I could imagine a transition with 5.7 for that, similar to gmp. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25 September 2014 09:21, Lester Caine wrote: > > 'This function returns a unique identifier for the object.' > There is a mistaken view in some usage that that will be DIFFERENT for > different versions of the same object. Not sure who has that view. It's quite clearly documented, for the lifetime of an object, it will always have the same hash. > So what *IS* returned by spl_object_hash? > The UCN from 7 years ago flags that the identifier is only based on the > internal pointers to the object in memory and that the result is not > user friendly, but without digging into the code, the problems such as > the fact that re-use of the buffer space by a later object cached in the > same buffer may be the same as ID? Yes it is created using various internal pointers, and is about as user-friendly as any other kind of hash. It is possible to create a duplicate hash if you unset an object, force GC collection, and then create a new object which can occupy the same memory location. var_dump(spl_object_hash(new stdClass())); gc_collect_cycles(); var_dump(spl_object_hash(new stdClass())); This is a fairly unrealistic scenario, however Joe Watkins has developed a better hash method that doesn't have this flaw, I don't know if he ever intended to have it applied to core or not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
Rowan Collins wrote (on 24/09/2014):
On 24/09/2014 22:33, Andrea Faulds wrote:
On 24 Sep 2014, at 22:17, Rowan Collins wrote:
Perhaps rather than a magic function or constant, though, the switch
statement could be extended with an "as" argument, which would store
the evaluated expression into a normal variable, allowing nesting,
and easier optimisation of the engine where the feature isn't used.
Thus you could write this:
switch( some_expression() as $switch_value ){
case 1:
do_something();
break;
//...
default:
throw new Exception('Undefined input: ' . $switch_value);
break;
}
Incredibly, some brave soul has gone back in time and already
implemented this, when none of us was looking!
switch($switch_value = some_expression()) {
...
}
Heh, now I feel like a fool for not thinking of that.
Treating assigments as expressions just isn't something that jumps to
mind, I guess!
Anyone have any thoughts on the use(operator) part, though?
Am I missing something equally obvious there? Or just, it doesn't
interest people much as an idea?
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25/09/14 08:44, Leigh wrote: > On 25 September 2014 08:40, Lester Caine wrote: >> > >> > Why would we need to build a hash of this object? It would provide >> > nothing of use since we have a clean object key. Some people seem to >> > think a hash will provide an indication that an object has changed, but >> > in reality that is also reliant on what information is imported when the >> > object is loaded. > Nothing to do with when the object is changed. > > http://php.net/spl_object_hash 'This function returns a unique identifier for the object.' There is a mistaken view in some usage that that will be DIFFERENT for different versions of the same object. So what *IS* returned by spl_object_hash? The UCN from 7 years ago flags that the identifier is only based on the internal pointers to the object in memory and that the result is not user friendly, but without digging into the code, the problems such as the fact that re-use of the buffer space by a later object cached in the same buffer may be the same as ID? It is not immediately obvious that using a buffer to load data to build a more compact array would have the SAME spl_object_hash for every entry ... -- 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
On Thu, Sep 25, 2014 at 7:28 AM, Daniel Lowrey wrote: > > FYI: I've tagged 5.6.1 and I had to revert the following commits for > this: > > 372844918a318ad712e16f9ec636682424a65403 > > f86b2193a483f56b0bd056570a0cdb57ebe66e2f > > 30a73658c63a91c413305a4c4d49882fda4dab3e > > 84a4041ba47e92e7a0ba03938d0ebf88b5fcf6cf > > 98e67add15a6b889efe152c23ed15a61f022a63a > > > > 98e67add15a6b889efe152c23ed15a61f022a63a and > 30a73658c63a91c413305a4c4d49882fda4dab3e were merge commits with conflict > resolution > > > > Could you review that the current status of ext/openssl/xp_ssl.c is > proper in the tag? > > Thanks! > > > > -- > > Ferenc Kovács > > Please also revert the following commit or we will still have problems: > > 6569db88081562f68a4f79e52cba83482bdf05fc > there is no need for that, that commit was merged with 98e67add15a6b889efe152c23ed15a61f022a63a, which I've already reverted, and it was better to revert the merge commit, because it contained modifications (because of conflict resolution back when you merged it). > > Other than this commit everything else looks good. I *have* verified a new > patch with the horde folks as solving the problem. However, I'm travelling > for the next week (starting in a couple of hours) and I don't want to rush > a (potentially) half-baked fix into the next 5.4 and 5.5 releases without > comprehensive testing. If tags must be created before the end of next week > then the best course of action is to revert these same commits for 5.4/5.5. > I will be able to respond to any correspondence if you have questions in > the coming days. Otherwise, I'll resolve this once and for all when I'm > back in the office. > have a safe trip! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
On 25 September 2014 08:42, Dmitry Stogov wrote: > Hi, > > The vote is opened at > https://wiki.php.net/rfc/fix_list_behavior_inconsistency > > Thanks. Dmitry. Since in the "should people be allowed to vote" thread, I said I think people should explain their votes, here is my explanation :) I am voting disable. +1 for consistency, but I think we already have a pretty rich suite of functions for working with strings that do not work with arrays, and vice versa. I think enabling list() to work on strings sets a precedent that more/all array handling mechanisms should be made to work with strings, and I'm not sure that's something we want. We've defined list as not working with strings in the manual, lets stick to our own definition. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
Hi! I'm typing on my phone at the airport so apologies for the brevity and lack of quoting from previous messages. I will summarize everything in detail with commit references to clear up any confusion in the next couple of days. I believe that by applying the patch below to the 5.4 and 5.5 branches as they exist currently everything is solved: https://bugs.php.net/patch-display.php?bug=41631&patch=bug41631.patch&revision=1411139621 However I ran out of time to perform the necessary due diligence and add test cases before traveling. In any case I will find time to summarize what needs to happen on-list as soon as I am able.
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25 September 2014 08:40, Lester Caine wrote: > > Why would we need to build a hash of this object? It would provide > nothing of use since we have a clean object key. Some people seem to > think a hash will provide an indication that an object has changed, but > in reality that is also reliant on what information is imported when the > object is loaded. Nothing to do with when the object is changed. http://php.net/spl_object_hash -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Fix list() behavior inconsistency
Hi, The vote is opened at https://wiki.php.net/rfc/fix_list_behavior_inconsistency Thanks. Dmitry.
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25/09/14 06:19, Patrick Schaaf wrote: > Am 24.09.2014 22:01 schrieb "Andrea Faulds" : >> > >> > Now, if we were to add actual object key support, that I might like. But > if we’re going to keep with just integers and strings, I’d much prefer to > just support __toString here. I think users are smart enough to understand > that PHP arrays only have string or int keys, so it casts to a string. > > Once you do that - automatically use __toString on objects used as keys, > the way to full object key support in the future, is completely blocked, > because BC. > > I'd much more like to see full object key support, with spl_object_hash or > a magic __hash() method only used to determine hash slot position > internally. The problem here is that while OOP has been brought into PHP it's rules have never been fully documented? Using a practical example, if I have an object for say an individual on a family tree data set, there are several elements that can be used as a key or an identifier that the content has changed. The unique ID will need to be used as a key, while a more display friendly 'toString' content including the full name may be more appropriate. We end up with additional functions to create more formalised control of the display functions. Why would we need to build a hash of this object? It would provide nothing of use since we have a clean object key. Some people seem to think a hash will provide an indication that an object has changed, but in reality that is also reliant on what information is imported when the object is loaded. I don't see anything here that can work 'automatically' and be practical? As with much of PHP, this is simply a matter of coding style, and providing a consistent style of object creation THAT IS IDEAL FOR YOUR APPLICATION. Much of the current automatic processes are a compromise and we may get better results by overriding those. Building in more guesses does not seem good practice, but we still do not have particularly good practical demonstrations on how to use much of these advanced features. Currently there is no requirement that __toString will produce a unique ID at all anyway? Adding a new function with that requirement just seems overkill. -- 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: OpenSSL bug in 5.4.33 and 5.5.17
Hi! > As you said, "5.4 is now supposed to be security-only" so I rather > think we should revert to 5.4.32 code and have the upcoming fix only > in 5.5+ (so in 5.5.18RC and 5.6.2RC) OK, I'll revert it then to 5.4.32 state tomorrow. But the problem is up-merging it - are there any fixes already committed? Should I try to preserve them and which ones? Or should I just revert everything there too and let the fixes that need to be re-applied be reapplied after the global revert? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: OpenSSL bug in 5.4.33 and 5.5.17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 25/09/2014 09:00, Stas Malyshev a écrit : > Hi! Hi, >> After a quick check Too quick, I miss 84a4041 ;) >> 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1 f86b219 >> and 3728449 are in 5.6.1RC1 only > > So, for 5.4 should we revert 6569db8 and 32be79d then? What about > upmerging to 5.5? What about f86b2193, should this be reverted > too? I'm feeling I don't understand what is going on there > completely. > In released 5.4.33 (and 5.5.17) you have 6569db8 + 84a4041 + 32be79d (notice I have revert these 3 patches for downstream) In 5.4/5.5/5.6 you have 6569db8 + 84a4041 + 32be79d + f86b219 + 3728449 (all reverted in 5.6.1) As you said, "5.4 is now supposed to be security-only" so I rather think we should revert to 5.4.32 code and have the upcoming fix only in 5.5+ (so in 5.5.18RC and 5.6.2RC) Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQjwrQACgkQYUppBSnxahj+lACgidyKYuSFEodjJ8sZf0+uOFLp Qt4An0zVL1DRvOB6nhVdBTbXwZrG4kIi =83AV -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
Hi! > I will review and report back on the 5.6.1 later today. I've checked with > the horde folks and my recent uncommitted patch resolves any bugs (both old > and new). I plan to commit this for 5.4 and 5.5 today and then subsequently What is this new patch? Please note 5.4 is now supposed to be security-only, so if we have more untested patches there it won't be good. I'd like to have some clarity on this ASAP as if we need fixes for 5.4 we're supposed to have RC next Tuesday and I'm not sure I understand what's going on there. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: OpenSSL bug in 5.4.33 and 5.5.17
Hi! > After a quick check > > 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1 > f86b219 and 3728449 are in 5.6.1RC1 only So, for 5.4 should we revert 6569db8 and 32be79d then? What about upmerging to 5.5? What about f86b2193, should this be reverted too? I'm feeling I don't understand what is going on there completely. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
