Tickets :: Comment on [#5604] ListMessages endless loop

* Your Email Address
* Spam protection	Enter the letters below: __. __.. __ . . (__ (__ \| / `\|\/\| .__).__)\|___\__.\| \|
Comment	>>> We need to cast it to an object, otherwise the JSON would probably > >>> look like this: > >>> > >>> [1, 2, 3] > >>> > >>> instead of: > >>> > >>> {'1': 1, '2': 2, '3': 3} > >> > >> This is precisely the reason. In javascript land, we are accessing > >> the array via the message index (our message indices just happen to > >> look like integers), which is a string value, rather than an integer > >> value because the latter would indicate the position in the JS array. > > > > Well, but if you look at your implementation of JSON serialization, > you handle asociative arrays differently than normal arrays. See also > comment in lib/Horde/Serialize/JSON.php:133 > > > > /* As per JSON spec if any array key is not an integer we > > * must treat the the whole array as an object. We also > > * try to catch a sparsely populated associative array > > * with numeric keys here because some JS engines will > > * create an array with empty indexes up to max_index > > * which can cause memory issues and because the keys, > > * which may be relevant, will be remapped otherwise. > > * > > * As per the ECMA and JSON specification an object may > > * have any string as a property. Unfortunately due to a > > * hole in the ECMA specification if the key is a ECMA > > * reserved word or starts with a digit the parameter is > > * only accessible using ECMAScript's bracket notation. */ > > > > According me it means, that casting associative array with string > keys to object is not required (and with cast to object it doesn't > work on probably somehow broken PHP in RHEL5/CentOS5 - I'll try to > figure out the reason why get_object_vars doesn't work on this > system, but right now I tested PHP 5.1.6 compiled from sources and it > doesn't work either).
Attachment
Watch this ticket

Saved Queries