On Wed, Feb 17, 2016 at 9:32 AM, François Laupretre wrote:
>
> Le 17/02/2016 00:26, Yasuo Ohgaki a écrit :
>>
>> I noticed one issue on {}
>> https://bugs.php.net/bug.php?id=71611
>>
>> echo "${str{1}}";
>>
>> raises syntax error while
>>
>> echo "{$str{1}}";
>>
>> works. Is this addressed?
>
>
>
Hi,
Le 17/02/2016 00:26, Yasuo Ohgaki a écrit :
I noticed one issue on {}
https://bugs.php.net/bug.php?id=71611
echo "${str{1}}";
raises syntax error while
echo "{$str{1}}";
works. Is this addressed?
No, this is a different problem. This RFC just adds support for negative
index values. It
Hi Francois,
I noticed one issue on {}
https://bugs.php.net/bug.php?id=71611
echo "${str{1}}";
raises syntax error while
echo "{$str{1}}";
works. Is this addressed?
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Jan 24, 2016 at 12:45 AM, François Laupretre wrote:
> Hi,
>
> Starting discussion
Le 15/02/2016 04:49, Stanislav Malyshev a écrit :
Hi!
This fix has been merged into master (targeting 7.1), thanks!
I'm not sure that was such a good idea (sorry, didn't have time to write
about it before the weekend). Introducing a new warning into previously
working code is a BC break, and
On Mon, 15 Feb 2016 08:16 Yasuo Ohgaki wrote:
> Hi all,
>
> On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev
> wrote:
> >> Another issue mentioned in this thread is the spurious array conversion
> >> that happens for empty strings. We have an existing bug report for this:
> >> https://bugs.p
Hi Pierre,
On Mon, Feb 15, 2016 at 4:01 PM, Pierre Joye wrote:
> On Feb 15, 2016 1:15 PM, "Yasuo Ohgaki" wrote:
>>
>> Hi all,
>>
>> On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev
>> wrote:
>> >> Another issue mentioned in this thread is the spurious array conversion
>> >> that happens for
On Feb 15, 2016 1:15 PM, "Yasuo Ohgaki" wrote:
>
> Hi all,
>
> On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev
> wrote:
> >> Another issue mentioned in this thread is the spurious array conversion
> >> that happens for empty strings. We have an existing bug report for
this:
> >> https://bugs
Hi all,
On Mon, Feb 15, 2016 at 12:49 PM, Stanislav Malyshev
wrote:
>> Another issue mentioned in this thread is the spurious array conversion
>> that happens for empty strings. We have an existing bug report for this:
>> https://bugs.php.net/bug.php?id=53432 I've created a PR to fix this
>> issu
Hi!
> This fix has been merged into master (targeting 7.1), thanks!
I'm not sure that was such a good idea (sorry, didn't have time to write
about it before the weekend). Introducing a new warning into previously
working code is a BC break, and one that wasn't even discussed in its
own thread. Mo
On Fri, Feb 12, 2016 at 12:44 AM, François Laupretre
wrote:
> Le 11/02/2016 17:25, Andrea Faulds a écrit :
>
>> Hi François,
>>
>> François Laupretre wrote:
>>
>>> String offsets are full of oddities :
>>>
>>> $str = "abc";
>>> $str{0} = '';
>>> var_dump($str); // -> string(3) "bc" (read as "\0bc
On 11/02/16 18:07, Stanislav Malyshev wrote:
>> It does not worth the effort having other RFCs for
>> > - $str{} = 'string'
> Correct, because nobody needs it and it is a bad idea.
>
>> > I agree small changes are easier to review, but it may leave lots of
>> > obvious inconsistency in PHP. We ha
Le 11/02/2016 17:25, Andrea Faulds a écrit :
Hi François,
François Laupretre wrote:
String offsets are full of oddities :
$str = "abc";
$str{0} = '';
var_dump($str); // -> string(3) "bc" (read as "\0bc")
Assigning an empty string to a string offset inserts a null byte because
the string lengt
Hi!
> Just having a different syntax, writing $foo{0} = 'zzz' instead of $foo[0]
> = 'zzz' does not make the implicit truncation behavior any more obvious or
> reasonable. If we want to actually make it less confusing, what we should
It makes it clear the operation you are dealing with is not a
Hi!
> Anyway, all of us know that main source of complaints about PHP is lack
> of consistency. Inconsistent APIs across modules are acceptable. It's
> modules after all. However, basic language constructs like [] and {} are
> better to have predictable/consistent behaviors. i.e. how it works, r
Hi François,
François Laupretre wrote:
String offsets are full of oddities :
$str = "abc";
$str{0} = '';
var_dump($str); // -> string(3) "bc" (read as "\0bc")
Assigning an empty string to a string offset inserts a null byte because
the string length is not checked in zend_assign_to_string_offs
Nikita Popov wrote on 11/02/2016 13:14:
The issue here is not an inherent problem with string offsets, it's
simply yet another artifact of PHP's overly lenient nature. If I
create an IntArray class that implements ArrayAccess, I don't think
you would be much surprised if doing $intArray[$i] = "
String offsets are full of oddities :
$str = "abc";
$str{0} = '';
var_dump($str); // -> string(3) "bc" (read as "\0bc")
Assigning an empty string to a string offset inserts a null byte because
the string length is not checked in zend_assign_to_string_offset().
I see this as a bug. IMO, this c
Le 11/02/2016 13:46, Rowan Collins a écrit :
Christoph Becker wrote on 11/02/2016 12:16:
Appending to an array always adds a single element only, consider
$a = [1,2,3];
$a[] = [4,5];
The suggested syntax for strings would concatenate an arbitrary amount
of elements (characters) to a stri
On Thu, Feb 11, 2016 at 1:46 PM, Rowan Collins
wrote:
> Christoph Becker wrote on 11/02/2016 12:16:
>
>> Appending to an array always adds a single element only, consider
>>
>>$a = [1,2,3];
>>$a[] = [4,5];
>>
>> The suggested syntax for strings would concatenate an arbitrary amount
>> of
Le 11/02/2016 13:16, Christoph Becker a écrit :
Appending to an array always adds a single element only, consider
$a = [1,2,3];
$a[] = [4,5];
The suggested syntax for strings would concatenate an arbitrary amount
of elements (characters) to a string. IMHO, this would not be
consistent,
Christoph Becker wrote on 11/02/2016 12:16:
Appending to an array always adds a single element only, consider
$a = [1,2,3];
$a[] = [4,5];
The suggested syntax for strings would concatenate an arbitrary amount
of elements (characters) to a string. IMHO, this would not be
consistent, but r
On 11.02.2016 at 12:12, Yasuo Ohgaki wrote:
> Anyway, all of us know that main source of complaints about PHP is lack
> of consistency. Inconsistent APIs across modules are acceptable. It's
> modules after all. However, basic language constructs like [] and {} are
> better to have predictable/con
Hi Stas,
On Thu, Feb 11, 2016 at 4:08 PM, Stanislav Malyshev wrote:
>> RFC must maintain consistency across existing features/specifications,
>
> There's a lot of things people call "consistency", apparently. I don't
> see inventing new syntax for doing concatenation to have anything to do
> with
Le 11/02/2016 07:27, Stanislav Malyshev a écrit :
Hi!
I just added support for '[]' on strings and '{}' to the PR.
Examples :
$string[] = 'a'; // equivalent to : $string[strlen($string)]
$string{} = 'a'; // For consistency
That's probably not a good idea, and certainly is not good for the
Hi!
> RFC must maintain consistency across existing features/specifications,
There's a lot of things people call "consistency", apparently. I don't
see inventing new syntax for doing concatenation to have anything to do
with consistency.
> make things worse certainly. Making patch and/or RFC sim
Hi Stas,
On Thu, Feb 11, 2016 at 3:27 PM, Stanislav Malyshev wrote:
>
>> I just added support for '[]' on strings and '{}' to the PR.
>>
>> Examples :
>>
>> $string[] = 'a'; // equivalent to : $string[strlen($string)]
>>
>> $string{} = 'a'; // For consistency
>
> That's probably not a good idea,
Hi!
> I just added support for '[]' on strings and '{}' to the PR.
>
> Examples :
>
> $string[] = 'a'; // equivalent to : $string[strlen($string)]
>
> $string{} = 'a'; // For consistency
That's probably not a good idea, and certainly is not good for the RFC -
the patch now does two unrelated t
On 10 February 2016 at 14:34, François Laupretre wrote:
> Hi,
>
> I just added support for '[]' on strings and '{}' to the PR.
>
> Examples :
>
> $string[] = 'a'; // equivalent to : $string[strlen($string)]
>
> $string{} = 'a'; // For consistency
Unless I'm missing some subtleties, that appears t
Le 10/02/2016 15:34, Dan Ackroyd a écrit :
On 10 February 2016 at 07:00, Yasuo Ohgaki wrote:
Additional comment on this
php > $v=array(1,2,3);
php > $v .= 'abc';
I think $v .= 'abc' should not destroy array variable. It's minor issue, though.
That is the current behaviour. Trying to slip "b
On 10 February 2016 at 07:00, Yasuo Ohgaki wrote:
> Additional comment on this
>
> php > $v=array(1,2,3);
> php > $v .= 'abc';
>
> I think $v .= 'abc' should not destroy array variable. It's minor issue,
> though.
That is the current behaviour. Trying to slip "bug fixes" into RFCs is
a very bad
Hi,
I just added support for '[]' on strings and '{}' to the PR.
Examples :
$string[] = 'a'; // equivalent to : $string[strlen($string)]
$string{} = 'a'; // For consistency
With this change, AFAIK, '{}' and '[]' notations are handled exactly the
same way (the only difference was that the con
On Wed, Feb 10, 2016 at 3:51 PM, Yasuo Ohgaki wrote:
> Behavior regarding array. (a bit off topic, but error level should
> match with new string '{}' errors.)
>
> php > error_reporting(-1);
> php > $v=array();
> php > $v .= 'abc';
>
> Notice: Array to string conversion in php shell code on line 1
Hi Francois,
On Tue, Feb 9, 2016 at 12:09 AM, François Laupretre wrote:
> Slightly off-topic but, as I was looking for the way to add support for
> '$str[]=' assignments, I found something strange.
>
> Just for curiosity, does someone know a reason for this :
>
> $str = "abc";
> $str[1]="z";
> va
Hi,
Slightly off-topic but, as I was looking for the way to add support for
'$str[]=' assignments, I found something strange.
Just for curiosity, does someone know a reason for this :
$str = "abc";
$str[1]="z";
var_dump($str); // -> string(3) "zbc" -> Expected
$str = ""; // Empty string
$str
Nikita Popov wrote on 06/02/2016 15:16:
In any case, while this is no doubt an interesting question, and one we
should resolve, it is tangential to this RFC and this RFC should make no
recommendations either way. I would prefer not to be forced to vote against
this RFC due to the inclusion of the
Le 06/02/2016 16:16, Nikita Popov a écrit :
In any case, while this is no doubt an interesting question, and one we
should resolve, it is tangential to this RFC and this RFC should make no
recommendations either way. I would prefer not to be forced to vote against
this RFC due to the inclusion o
Hi!
> if it means one has to take a brief look in the manual. String offset is
> *not* the same as array access.
>
>
> What are these subtle differences?
Negative indexes, string indexes. Array offset is a variable, so it can
be used by-ref, but string offset can not. You can substitute
On Mon, Feb 1, 2016 at 10:06 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > I strongly disagree with this. $str[$offset] is well-recognized,
> > generally understood syntax that does not require familiarity with
> > language peculiarities. $str{$offset} might be clear to a Perl
> > programmer, but to
Den 2016-02-01 kl. 22:06, skrev Stanislav Malyshev:
> Hi!
>
>> I strongly disagree with this. $str[$offset] is well-recognized,
>> generally understood syntax that does not require familiarity with
>> language peculiarities. $str{$offset} might be clear to a Perl
>> programmer, but to anyone else
Hi!
> I strongly disagree with this. $str[$offset] is well-recognized,
> generally understood syntax that does not require familiarity with
> language peculiarities. $str{$offset} might be clear to a Perl
> programmer, but to anyone else this is just guesswork, with a typo being
> a reasonable ass
> We should be deprecating this alternative syntax instead of recommending
> its use. I was under the impression that we *were* already discouraging its
> use and it has already been temporarily deprecated.
I agree with Nikita. I think we should be deprecating and removing
`{}` access in favor of
On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > The only concern I have is that support of negative indexing will break
> > symmetry with (proper) arrays, where we cannot support negative indexing.
>
> I think that was the main source of objections to this proposal in the
Le 31/01/2016 23:14, Stanislav Malyshev a écrit :
Hi!
The only concern I have is that support of negative indexing will break
symmetry with (proper) arrays, where we cannot support negative indexing.
I think that was the main source of objections to this proposal in the
past. However, as one
On Sun, Jan 31, 2016 at 11:14 PM, Stanislav Malyshev
wrote:
> Hi!
>
>> The only concern I have is that support of negative indexing will break
>> symmetry with (proper) arrays, where we cannot support negative indexing.
>
> I think that was the main source of objections to this proposal in the
> p
Hi!
> The only concern I have is that support of negative indexing will break
> symmetry with (proper) arrays, where we cannot support negative indexing.
I think that was the main source of objections to this proposal in the
past. However, as one might say, string offsets are already not
symmetri
On Sat, Jan 23, 2016 at 4:45 PM, François Laupretre
wrote:
> Hi,
>
> Starting discussion about https://wiki.php.net/rfc/negative-string-offsets
>
> Please read and comment.
>
Just dropping by with a +1 on this proposal. Consistent support is always
good.
The only concern I have is that support
46 matches
Mail list logo
