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?
--
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//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
