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

Reply via email to