On Mon, Dec 28, 2009 at 4:39 PM, Tjerk Meesters
wrote:
> On 28-Dec-2009, at 20:39, Ferenc Kovacs wrote:
>
>> On Mon, Dec 28, 2009 at 11:58 AM, jvlad wrote:
Do you think we are deprecating split() just for fun?
>>>
>>> Yes, exactly. It's just made for _fun_ by core developers and brough
On Mon, Dec 28, 2009 at 4:07 PM, jvlad wrote:
>> as far as I see, the changes depends on how many work has to be done,
>> to preserve something.
>
> I see the same.
>
>> posix functions like split, and so could have been modified to work
>> with the unicode strings, but nobody cared enough.
>
> Be
On 28-Dec-2009, at 20:39, Ferenc Kovacs wrote:
On Mon, Dec 28, 2009 at 11:58 AM, jvlad wrote:
Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for _fun_ by core developers and brought
headache
to people developing in php.
We are letting you know that you n
> as far as I see, the changes depends on how many work has to be done,
> to preserve something.
I see the same.
> posix functions like split, and so could have been modified to work
> with the unicode strings, but nobody cared enough.
Because this work is not in the TODO (milestones).
-jv
>> > We are letting you know that you need to start thinking about
>> > migrating your code away from non-Unicode aware functions like
>> > ereg() and split().
>>
>> Well, this filled up my php logs with some million records telling me
>> this! Do you think it's safer to keep thinking and have an o
On Mon, 28 Dec 2009, jvlad wrote:
> > We are letting you know that you need to start thinking about
> > migrating your code away from non-Unicode aware functions like
> > ereg() and split().
>
> Well, this filled up my php logs with some million records telling me
> this! Do you think it's saf
On Mon, Dec 28, 2009 at 11:58 AM, jvlad wrote:
>> Do you think we are deprecating split() just for fun?
>
> Yes, exactly. It's just made for _fun_ by core developers and brought
> headache
> to people developing in php.
>
>> We are letting you know that you need to start thinking about migrating
>
> Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for _fun_ by core developers and brought
headache
to people developing in php.
> We are letting you know that you need to start thinking about migrating
> your code away from non-Unicode aware functions like ere
> jvlad wrote:
>>> $a = array(1);
>>> $b = 0;
>>> $c = &$b;
>>> foreach($a as $c);
>>> Now you are arguing that $b should not be 1?
>>> The two pieces of code are identical
>>
>> It's just a nightmare example. I wonder have you ever see anything like
>> this
>> in real life?
>> Could you please le
jvlad wrote:
> Meanwhile I see that php core developers and Evangelist propose the way of
> evolving difficulties.
> For example, I used split() for many many years. Now it throws a warning and
> it appears
> that this function will be removed soon. I have to rewrite all my scripts
> and replace
jvlad wrote:
>> $a = array(1);
>> $b = 0;
>> $c = &$b;
>> foreach($a as $c);
>> Now you are arguing that $b should not be 1?
>> The two pieces of code are identical
>
> It's just a nightmare example. I wonder have you ever see anything like this
> in real life?
> Could you please let me see it to
>
> No chance. No .ini settings, and I still maintain it is inconsistent.
>
> So, if I write this:
>
> $a = array(1);
> $b = 0;
> $c = &$b;
> $c = $a[0];
>
> Would you agree that $b should be 1 at this point? If so, just because
> I rewrite that code like this:
>
> $a = array(1);
> $b = 0;
> $c =
jvlad wrote:
> "Rasmus Lerdorf" wrote in message
> news:4b3785ac.2000...@lerdorf.com...
>> We can't just randomly reset variables based on their scope in this one
>> specific case. If we are going to "fix" this, it should be done by
>> introducing a way to do proper local scope variables. Reset
"Rasmus Lerdorf" wrote in message
news:4b3785ac.2000...@lerdorf.com...
> We can't just randomly reset variables based on their scope in this one
> specific case. If we are going to "fix" this, it should be done by
> introducing a way to do proper local scope variables. Resetting a
> reference s
Rasmus Lerdorf wrote:
We can't just randomly reset variables based on their scope in this one
specific case. If we are going to "fix" this, it should be done by
introducing a way to do proper local scope variables. Resetting a
reference simply because it is convenient in this one case would be
We can't just randomly reset variables based on their scope in this one
specific case. If we are going to "fix" this, it should be done by
introducing a way to do proper local scope variables. Resetting a
reference simply because it is convenient in this one case would be
completely inconsistent.
On Sun, Dec 27, 2009 at 3:11 PM, Mike Wacker wrote:
> Adam Harvey wrote:
>>
>> 2009/12/27 Mike Wacker :
>>>
>>> PHP's documentation for foreach states that if you iterate by reference
>>> [foreach ($ii as &$i) ...], you should unset $i after the loop. $i still
>>> points to the last element of th
Adam Harvey wrote:
2009/12/27 Mike Wacker :
PHP's documentation for foreach states that if you iterate by reference
[foreach ($ii as &$i) ...], you should unset $i after the loop. $i still
points to the last element of the array - updating $i or reusing it will
update the last element of the ar
2009/12/27 Mike Wacker :
> PHP's documentation for foreach states that if you iterate by reference
> [foreach ($ii as &$i) ...], you should unset $i after the loop. $i still
> points to the last element of the array - updating $i or reusing it will
> update the last element of the array.
>
> In sh
19 matches
Mail list logo
