On Thu, May 23, 2013 at 07:35:51PM +0200, Arne Goedeke wrote: > Unfortunately, its not that simple. Assume > ([ 1 : 0, 2 : 0, 3 : 0 ]) > and a callback that always returns "\"foo\"". "\"foo\"" would not be found in > the mapping and therefore lead to invalid json
ah, right, i'd have to keep track of the new keys as well. > Maybe my argument is overly pedantic: Currently, using encode_json() one > can already create invalid json. mind you, i am arguing on your side :-) but yes, also, there is a difference between the ability to control what the callback returns, and to control the original data. getting an error when the callback result conflicts with original data is more needed than an error about returning the same value multiple times, because presumably i can figure out the latter myself more easely. more so, for a truly save output we'd need to parse the callback result to verify that it is valid json, or let the callback return a pike datastructure. that would be interesting, because it could mean that for an object the callback could return a mapping which would result in a valid JSON object. (this brings up some other ideas: without an encode function, what about casting objects to a mapping or an array? presumably if an object supports such a cast, then the cast result is equivalent to the original object? for keys, an automatic cast to string could be applied. (though this would be ugly if the key is an array or mapping, but that's another edge-case)) > I guess my opposition to more hooks is that somewhere down the > road that callback solution is not flexible enough. In particular your > callback might want to encode objects as some string in case they are > mapping keys but treat them differently, if they are not. How do you > tell the difference? Of course that could be solved by either having two > callbacks or passing some kind of flag... i have been thinking about that too. it partly inspired the suggestion if maybe the key:value pair should be passed or the whole mapping. either way though, i'd prefer to start with a simple solution. not knowing the difference between keys and values is still better than not handling keys at all, which is currently the case. we can always improve on that later if it is needed. > Its seems more reasonable to me to have a limited set of tweaks; what do you mean by limited set of tweaks? as opposed to one callback argument? the main thing i am concerned about is to be able to convert arbitrary datastructures to json without throwing an error or needing an expensive walk through the datastructure to weed out bad values. the latter is what i currently need to do if i want to prevent my application to stop working because a user somewhere decided to add a mapping with problematic keys. (it's not urgent because for the moment the only way to add that mapping would be by uploading it via json in the first place. but that will change later when we expose other APIs.) greetings, martin.
