On 25/09/2014 09:42, Dmitry Stogov wrote:
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Thanks. Dmitry.
Hi,
After discussing this RFC with a few other members of AFUP (French UG),
we agree *something* should be done, to get to a consistent behavior:
ei
nothing was changed in RFC itself, just additional details were clarified
during discussion.
I didn't thought about ArrayAccess when found this inconsistency.
Anyway, I won't object if someone will add missing info about ArrayAccess
support inconsistency and restart the voting.
Thanks. Dmitry.
O
2014-09-25 17:27 GMT+02:00 Patrick ALLAERT :
> 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
> warn
On Thu, 25 Sep 2014, Lars Strojny wrote:
> 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
On 26 Sep 2014, at 14:25, Pierre Joye wrote:
> On Fri, Sep 26, 2014 at 2:30 PM, Dmitry Stogov wrote:
>> When I started this RFC I didn't thought about objects.
>> Actually, they are handled with the same inconsistency problem.
>>
>> Nikita, feel free to add this note to RFC.
>> May be it'll ch
On Fri, Sep 26, 2014 at 2:30 PM, Dmitry Stogov wrote:
> When I started this RFC I didn't thought about objects.
> Actually, they are handled with the same inconsistency problem.
>
> Nikita, feel free to add this note to RFC.
> May be it'll change mind of some voters :)
>
> also add a link to your
On 26 Sep 2014, at 14:11, Dmitry Stogov wrote:
> just change your vote.
> I just did it. :)
>
> Even if ArrayAccess worked not by design, it's going to be a big
> compatibility issue, removing it.
> Strings support would work for free.
What should I vote then? I want to vote against string s
just change your vote.
I just did it. :)
Even if ArrayAccess worked not by design, it's going to be a big
compatibility issue, removing it.
Strings support would work for free.
Thanks. Dmitry,
On Fri, Sep 26, 2014 at 5:03 PM, Andrea Faulds wrote:
>
> On 26 Sep 2014, at 11:11, Nikita Popov w
On 26 Sep 2014, at 11:11, Nikita Popov wrote:
> So, just to clarify: If we vote to "remove string handling in all cases"
> does that also mean that we "remove ArrayAccess support in all cases"? If
> so, could the RFC please explicitly mention that?
I myself would be in favour of removing string
When I started this RFC I didn't thought about objects.
Actually, they are handled with the same inconsistency problem.
Nikita, feel free to add this note to RFC.
May be it'll change mind of some voters :)
also add a link to your patch.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 2:11 PM, Nikita Po
On Thu, Sep 25, 2014 at 11:47 PM, Dmitry Stogov wrote:
> It was on design. list() was intended to support plain arrays only.
>
> Thanks. Dmitry.
>
So, just to clarify: If we vote to "remove string handling in all cases"
does that also mean that we "remove ArrayAccess support in all cases"? If
so
It's an inconsistent undocumented behavior, that started to work not by
design, but because of implementation issues.
NULL
NULL
By the way, I'm agree, keeping string support might be better for
compatibility.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 11:16 AM, Stas Malyshev
wrote:
> Hi!
>
> >
Hi!
> and weird to me, and can be quickly emulated with list($a,$b) =
> str_split([“ab”][0]); if someone was actually using it.
BC breaks don't work this way. When somebody's code would break on PHP
7, their first move would not be "oh, great, let's refactor it, it was
too arcane anyway". It woul
On Sep 25, 2014, at 2:42, Dmitry Stogov wrote:
> Hi,
>
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>
> Thanks. Dmitry.
Voting for always disabling string handling. This behavior is arcane and weird
to me, and can be quickly emulated with list($a,$b) = st
On Sep 25, 2014, at 2:42, Dmitry Stogov wrote:
> Hi,
>
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>
> Thanks. Dmitry.
Voting for always disabling string handling. This behavior is arcane and weird
to me, and can be quickly emulated with list($a,$b) = st
On 26/09/14 08:08, Leigh wrote:
> My points are:
>
> * Strings are _not_ treated as arrays of bytes everywhere.
> * If we intend to give strings more array-like support after this RFC
> (like foreach($string as $char), making array_* work with strings),
> then I support the list() change.
> * Othe
Hi!
> * Strings are _not_ treated as arrays of bytes everywhere.
This is true. However, sometimes they are. E.g., $string[0] is
meaningful, while array_flip($string) is not.
> * If we intend to give strings more array-like support after this RFC
We don't intend to give strings anything - both $
On 26 September 2014 08:01, Stas Malyshev wrote:
>
> It's as odd as [] working with strings but -> not. Those are different
> things, so they work differently.
Sorry, this was kind of my point, I probably just phrased it badly.
The array_* "question" was meant to be rhetorical.
My points are:
*
Hi!
> 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://gi
Hi!
> Why do array_* functions not treat strings as arrays of bytes?
How that's related? We're not talking about array_* functions, we're
talking about list() operator.
> get busy :) - If we want to say "yea list() should work with strings",
> but no other array functions should work with string
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 s
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.
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 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
"ena
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
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?
>
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
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
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 d
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_FETC
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
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
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 po
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 inc
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 s
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
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Thanks. Dmitry.
37 matches
Mail list logo
