I'd like to reiterate -- this is going about it backwards.

You do NOT want errors to go undetected.

You do NOT want data that you may have expected to be captured to be
SILENTLY discarded.

You do not want YOUR BUG to be papered over!  You want your  bugs to be IN
YOUR FACE IN ALL CAPS SHOUTING AT YOU! :=)  Or at least, hard-to-miss.

I agree, we don't want to replace the native implementation. But to take
your idea, and rework it -- Prototype could supply a a validateJSON()
routine, that checks for, and objects to, invalid output -- and perhaps puts
a configurable limit on depth of recursion, or total size. The input would
be returned, unmodified, if it is acceptable, otherwise an exception would
be thrown.

Depending on need, this could be injected during debug/test only, or during
production. (Performance isn't ALWAYS a problem).

It might also POSSIBLY be useful to have a filterObject() function that
traverses some hierarchy, and applies a predicate, which if true, results in
that key/value pair being included in the result. It would make a copy iff
the result were not identical to the input, and would return the result.

This would have other application -- for example, rejecting attempts to
insert additional data, or filtering out private information, or taking a
recursive structure and returning a hierarchical version for transmission.

This is different from just papering over the bug. It is making an explicit
decision about the datastructure you transmit, rather than relying on the
behavior of the underlying system to not fail given broken inputs.

I would still question your architecture, if you are using it in this way --
I think it suggests that there may be poor modularization at work. I'd take
a good look at whether the information to be transmitted would be better
separated from the information that contains live data, perhaps with a level
of indirection (a side lookup table). I suspect you'd find such an approach
to be more flexible and better in the long run anyway. But that's a
suspicion, not a conclusion; I'll leave it to you to ponder whether it fits
your situation.

The other question is whether either of these ideas has enough wide-spread
value to be worth implementing -- and then to be loaded into millions upon
millions of browser sessions.  Personally, I think I'd just write them
myself if I need them -- they're not difficult -- but it might be worth it
they encourage people to write better code or test it better. But my default
position here is, "we don't need it in Prototype", but if you write it,
they'd be worth sharing some other way.

Perhaps a parallel package of debugging tools you load, and enable, to add
additional error checking.

On Sat, Mar 5, 2011 at 5:03 AM, Mislav Marohnić
<mislav.maroh...@gmail.com>wrote:

> On Sat, Mar 5, 2011 at 10:58, andris <andris.rein...@gmail.com> wrote:
>
>>
>> But just to be clear - I didn't want Prototype to force *other*
>> browsers to behave as WebKit but to force WebKit to behave as others.
>> So when I do Object.toJSON({elm:HTMLDIVElement}) it wouldn't end on
>> error but with {elm:{}} instead.
>
>
> I agree with Andrew that Prototype shouldn't do anything in this regard.
> You've got a good point that it's the job of a JS library to smooth out such
> inconsistencies, but any meddling in this case would result in slowdowns.
>
> There could exist a Prototype plugin which performs a simple traversal of
> the array/hash before sending it to JSON encoder, and if it finds properties
> that reference DOM elements it could blank those out. Someone whose JS app
> suffers from these DOM references creeping in their JSON data might want to
> use such plugin.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prototype: Core" group.
> To post to this group, send email to prototype-core@googlegroups.com
> To unsubscribe from this group, send email to
> prototype-core-unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/prototype-core?hl=en
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en

Reply via email to