JSON decoding

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

JSON decoding

Rob Sayre-2
I'm pretty sure the group accepted some form of Crockford's parseJSON
proposal, but I think it would be handy to add something analogous to
simplejson's object_hook argument. One weakness JSON has is annotating
literals (like strings with custom attributes), and this facility can
make that smoother.

<http://svn.red-bean.com/bob/simplejson/trunk/docs/module-simplejson.html#load>

See "Specializing JSON object decoding" above as well.

--

Robert Sayre

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
On Oct 11, 2006, at 3:06 PM, Robert Sayre wrote:

> I'm pretty sure the group accepted some form of Crockford's parseJSON
> proposal, but I think it would be handy to add something analogous to
> simplejson's object_hook argument. One weakness JSON has is annotating
> literals (like strings with custom attributes), and this facility can
> make that smoother.
>
> <http://svn.red-bean.com/bob/simplejson/trunk/docs/module- 
> simplejson.html#load>
>
> See "Specializing JSON object decoding" above as well.

Thanks, the wiki will be re-exported after the next face-to-face TG1  
meeting (which is the end of next week).  We should have finalized  
the JSON APIs by then.  We were already considering an optional  
filter funarg, but Bob's object_hook is more powerful.  I've added a  
comment to the wiki with that link.

/be

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
On Oct 11, 2006, at 8:06 PM, Brendan Eich wrote:

> On Oct 11, 2006, at 3:06 PM, Robert Sayre wrote:
>
>> I'm pretty sure the group accepted some form of Crockford's parseJSON
>> proposal, but I think it would be handy to add something analogous to
>> simplejson's object_hook argument. One weakness JSON has is  
>> annotating
>> literals (like strings with custom attributes), and this facility can
>> make that smoother.
>>
>> <http://svn.red-bean.com/bob/simplejson/trunk/docs/module- 
>> simplejson.html#load>
>>
>> See "Specializing JSON object decoding" above as well.
>
> Thanks, the wiki will be re-exported after the next face-to-face  
> TG1 meeting (which is the end of next week).  We should have  
> finalized the JSON APIs by then.  We were already considering an  
> optional filter funarg, but Bob's object_hook is more powerful.  
> I've added a comment to the wiki with that link.

Sneak preview (wiki re-export coming soon) of Doug Crockford's latest  
rev of the proposal:

JSON encoding and decoding

The following built-in functions facilitate handling JSON data, as  
specified in Douglas Crockford's RFC 4627.
Encoding

     * Object.prototype.toJSONString( filter , pretty )

Returns a String containing the JSON representation of an object,  
array, date, string, number, boolean, or null . The proto link is not  
used when finding members. A Date object is serialized as an ISO date  
string in double quotes. An Array object is serialized as a sequence  
of comma separated values wrapped in square brackets. Otherwise, an  
object is serialized as a a sequenced of comma separated pairs  
wrapped in curly braces. A string is serialized as a quoted string  
with backslash escapement. A finite number is serialized by toString.  
true , false , and null are encoded an unquoted strings. See http://
www.ietf.org/rfc/rfc4627.txt?number=4627

An encodingError will be thrown if the encoder reache a value which

     * cannot be encoded as valid JSON (such as a function,  
undefined, and NaN) OR
     * represents a cycle (as happens when an object has a property  
that refers to itself)

Recurring objects which do not cause cycles are allowed, but will  
produce a complete text for each occurrence.

A filter is an optional function which takes two parameters: a name  
and a value. The function will be called for each candidate pair in  
each object being serialized. If the function returns true, then the  
pair will be included. If the function returns false, then the pair  
will be excluded. If the function returns any other value, or if it  
throws, then an encodingError exception is thrown.

If the pretty parameter is true, then linefeeds are inserted after  
each { , [ , and , and before } and ] , and multiples of 4 spaces are  
inserted to indicate the level of nesting, and one space will be  
inserted after : . Otherwise, no whitespace is inserted between the  
tokens.
Decoding

     * String.prototype.parseJSON( hook )

Returns the value represented by the string. A syntaxError is thrown  
if the string was not a strict JSON text.

The optional hook function will be called for each object value  
found. It is passed each object. Its return value will be used  
instead of the object in the final structure.
-----

I like this proposal a lot; it avoids too many bells and whistles,  
and captures the desired (different) hooks for encoding and decoding,  
as well as pretty-encoding.  Comments?

/be

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Erik Arvidsson
If Date is serialized as an ISO strings the process of encoding and
decoding loses information. If Dates are added to JSON then they
should be encoded using new Date(ms). However Dates are not supported
in JSON today and removing them from JS2 seems OK.

On 10/20/06, Brendan Eich <[hidden email]> wrote:

> On Oct 11, 2006, at 8:06 PM, Brendan Eich wrote:
>
> > On Oct 11, 2006, at 3:06 PM, Robert Sayre wrote:
> >
> >> I'm pretty sure the group accepted some form of Crockford's parseJSON
> >> proposal, but I think it would be handy to add something analogous to
> >> simplejson's object_hook argument. One weakness JSON has is
> >> annotating
> >> literals (like strings with custom attributes), and this facility can
> >> make that smoother.
> >>
> >> <http://svn.red-bean.com/bob/simplejson/trunk/docs/module-
> >> simplejson.html#load>
> >>
> >> See "Specializing JSON object decoding" above as well.
> >
> > Thanks, the wiki will be re-exported after the next face-to-face
> > TG1 meeting (which is the end of next week).  We should have
> > finalized the JSON APIs by then.  We were already considering an
> > optional filter funarg, but Bob's object_hook is more powerful.
> > I've added a comment to the wiki with that link.
>
> Sneak preview (wiki re-export coming soon) of Doug Crockford's latest
> rev of the proposal:
>
> JSON encoding and decoding
>
> The following built-in functions facilitate handling JSON data, as
> specified in Douglas Crockford's RFC 4627.
> Encoding
>
>      * Object.prototype.toJSONString( filter , pretty )
>
> Returns a String containing the JSON representation of an object,
> array, date, string, number, boolean, or null . The proto link is not
> used when finding members. A Date object is serialized as an ISO date
> string in double quotes. An Array object is serialized as a sequence
> of comma separated values wrapped in square brackets. Otherwise, an
> object is serialized as a a sequenced of comma separated pairs
> wrapped in curly braces. A string is serialized as a quoted string
> with backslash escapement. A finite number is serialized by toString.
> true , false , and null are encoded an unquoted strings. See http://
> www.ietf.org/rfc/rfc4627.txt?number=4627
>
> An encodingError will be thrown if the encoder reache a value which
>
>      * cannot be encoded as valid JSON (such as a function,
> undefined, and NaN) OR
>      * represents a cycle (as happens when an object has a property
> that refers to itself)
>
> Recurring objects which do not cause cycles are allowed, but will
> produce a complete text for each occurrence.
>
> A filter is an optional function which takes two parameters: a name
> and a value. The function will be called for each candidate pair in
> each object being serialized. If the function returns true, then the
> pair will be included. If the function returns false, then the pair
> will be excluded. If the function returns any other value, or if it
> throws, then an encodingError exception is thrown.
>
> If the pretty parameter is true, then linefeeds are inserted after
> each { , [ , and , and before } and ] , and multiples of 4 spaces are
> inserted to indicate the level of nesting, and one space will be
> inserted after : . Otherwise, no whitespace is inserted between the
> tokens.
> Decoding
>
>      * String.prototype.parseJSON( hook )
>
> Returns the value represented by the string. A syntaxError is thrown
> if the string was not a strict JSON text.
>
> The optional hook function will be called for each object value
> found. It is passed each object. Its return value will be used
> instead of the object in the final structure.
> -----
>
> I like this proposal a lot; it avoids too many bells and whistles,
> and captures the desired (different) hooks for encoding and decoding,
> as well as pretty-encoding.  Comments?
>
> /be
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>


--
erik

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Bob Ippolito
In reply to this post by Brendan Eich-2
On 10/20/06, Brendan Eich <[hidden email]> wrote:

> On Oct 11, 2006, at 8:06 PM, Brendan Eich wrote:
>
> > On Oct 11, 2006, at 3:06 PM, Robert Sayre wrote:
> >
> >> I'm pretty sure the group accepted some form of Crockford's parseJSON
> >> proposal, but I think it would be handy to add something analogous to
> >> simplejson's object_hook argument. One weakness JSON has is
> >> annotating
> >> literals (like strings with custom attributes), and this facility can
> >> make that smoother.
> >>
> >> <http://svn.red-bean.com/bob/simplejson/trunk/docs/module-
> >> simplejson.html#load>
> >>
> >> See "Specializing JSON object decoding" above as well.
> >
> > Thanks, the wiki will be re-exported after the next face-to-face
> > TG1 meeting (which is the end of next week).  We should have
> > finalized the JSON APIs by then.  We were already considering an
> > optional filter funarg, but Bob's object_hook is more powerful.
> > I've added a comment to the wiki with that link.
>
> Sneak preview (wiki re-export coming soon) of Doug Crockford's latest
> rev of the proposal:
>
> JSON encoding and decoding
>
> The following built-in functions facilitate handling JSON data, as
> specified in Douglas Crockford's RFC 4627.
> Encoding
>
>      * Object.prototype.toJSONString( filter , pretty )
>
> Returns a String containing the JSON representation of an object,
> array, date, string, number, boolean, or null . The proto link is not
> used when finding members. A Date object is serialized as an ISO date
> string in double quotes. An Array object is serialized as a sequence
> of comma separated values wrapped in square brackets. Otherwise, an
> object is serialized as a a sequenced of comma separated pairs
> wrapped in curly braces. A string is serialized as a quoted string
> with backslash escapement. A finite number is serialized by toString.
> true , false , and null are encoded an unquoted strings. See http://
> www.ietf.org/rfc/rfc4627.txt?number=4627
>
> An encodingError will be thrown if the encoder reache a value which
>
>      * cannot be encoded as valid JSON (such as a function,
> undefined, and NaN) OR
>      * represents a cycle (as happens when an object has a property
> that refers to itself)
>
> Recurring objects which do not cause cycles are allowed, but will
> produce a complete text for each occurrence.
>
> A filter is an optional function which takes two parameters: a name
> and a value. The function will be called for each candidate pair in
> each object being serialized. If the function returns true, then the
> pair will be included. If the function returns false, then the pair
> will be excluded. If the function returns any other value, or if it
> throws, then an encodingError exception is thrown.
>
> If the pretty parameter is true, then linefeeds are inserted after
> each { , [ , and , and before } and ] , and multiples of 4 spaces are
> inserted to indicate the level of nesting, and one space will be
> inserted after : . Otherwise, no whitespace is inserted between the
> tokens.
> Decoding
>
>      * String.prototype.parseJSON( hook )
>
> Returns the value represented by the string. A syntaxError is thrown
> if the string was not a strict JSON text.
>
> The optional hook function will be called for each object value
> found. It is passed each object. Its return value will be used
> instead of the object in the final structure.
> -----
>
> I like this proposal a lot; it avoids too many bells and whistles,
> and captures the desired (different) hooks for encoding and decoding,
> as well as pretty-encoding.  Comments?

Encoding seems incredibly weak. You can put Date objects in, but
you'll never get a Date object back out. The filter function seems
really bizarre and a little useless. Why key:value pair? Why no
context? No opportunity for object replacement?

Decoding looks great, though.

-bob

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
In reply to this post by Erik Arvidsson
On Oct 20, 2006, at 3:36 PM, Erik Arvidsson wrote:

> If Date is serialized as an ISO strings the process of encoding and
> decoding loses information. If Dates are added to JSON then they
> should be encoded using new Date(ms). However Dates are not supported
> in JSON today and removing them from JS2 seems OK.

ES4 also standardizes Date.parse to accept the same ISO 8601 date  
strings, so I don't believe any information is lost.

You're right that this automatic encoding of Date objects as ISO  
strings does not result, when decoding, in Date objects again.  
Fixing that would require a pass over the decoded structure, or a use  
of the optional object hook on the enclosing object.  Is this a problem?

/be

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Bob Ippolito
On 10/20/06, Brendan Eich <[hidden email]> wrote:
> On Oct 20, 2006, at 3:36 PM, Erik Arvidsson wrote:
>
> > If Date is serialized as an ISO strings the process of encoding and
> > decoding loses information. If Dates are added to JSON then they
> > should be encoded using new Date(ms). However Dates are not supported
> > in JSON today and removing them from JS2 seems OK.
>
> ES4 also standardizes Date.parse to accept the same ISO 8601 date
> strings, so I don't believe any information is lost.

Even if there wasn't, you can always turn strings into dates the hard
way as MochiKit does...

The important part is that the metadata that it is a date is lost,
even if there's an easy way to make dates from strings. You have to
know which strings should be treated as dates.

> You're right that this automatic encoding of Date objects as ISO
> strings does not result, when decoding, in Date objects again.
> Fixing that would require a pass over the decoded structure, or a use
> of the optional object hook on the enclosing object.  Is this a problem?

The object hook would be no good here because it would have to be able
to find ISO strings by key (or regexing all string values looking for
dates.. bleh).

-bob

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
On Oct 20, 2006, at 3:51 PM, Bob Ippolito wrote:

> On 10/20/06, Brendan Eich <[hidden email]> wrote:
>> On Oct 20, 2006, at 3:36 PM, Erik Arvidsson wrote:
>>
>> > If Date is serialized as an ISO strings the process of encoding and
>> > decoding loses information. If Dates are added to JSON then they
>> > should be encoded using new Date(ms). However Dates are not  
>> supported
>> > in JSON today and removing them from JS2 seems OK.
>>
>> ES4 also standardizes Date.parse to accept the same ISO 8601 date
>> strings, so I don't believe any information is lost.
>
> Even if there wasn't, you can always turn strings into dates the hard
> way as MochiKit does...

Sure.  That was more an FYI (ECMA-262 left Date.parse unspecified, a  
botch that requires browsers to reverse engineer IE JScript's  
Date.parse implementation).

> The important part is that the metadata that it is a date is lost,
> even if there's an easy way to make dates from strings. You have to
> know which strings should be treated as dates.

You're right, but JSON does not provide any way to distinguish this  
case (preserve the bit of metadata you cite).

>> You're right that this automatic encoding of Date objects as ISO
>> strings does not result, when decoding, in Date objects again.
>> Fixing that would require a pass over the decoded structure, or a use
>> of the optional object hook on the enclosing object.  Is this a  
>> problem?
>
> The object hook would be no good here because it would have to be able
> to find ISO strings by key (or regexing all string values looking for
> dates.. bleh).

The context would have to determine what's a date and what is not.  
Yeah, it's poor, but without extending JSON, what can be done?

/be

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Erik Arvidsson
In reply to this post by Brendan Eich-2
[Replying all this time]

Yes. This is a problem because you cannot tell if the data contained a
String or a Date.

({string: "20061020125156", date: new Date}).toJSONString() ->
{"string":"20061020125156","date":"20061020125156"}

...like Bob said...

On 10/20/06, Brendan Eich <[hidden email]> wrote:

> On Oct 20, 2006, at 3:36 PM, Erik Arvidsson wrote:
>
> > If Date is serialized as an ISO strings the process of encoding and
> > decoding loses information. If Dates are added to JSON then they
> > should be encoded using new Date(ms). However Dates are not supported
> > in JSON today and removing them from JS2 seems OK.
>
> ES4 also standardizes Date.parse to accept the same ISO 8601 date
> strings, so I don't believe any information is lost.
>
> You're right that this automatic encoding of Date objects as ISO
> strings does not result, when decoding, in Date objects again.
> Fixing that would require a pass over the decoded structure, or a use
> of the optional object hook on the enclosing object.  Is this a problem?
>
> /be
>


--
erik

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Rob Sayre-2
In reply to this post by Brendan Eich-2
On 10/20/06, Brendan Eich <[hidden email]> wrote:
>
> The context would have to determine what's a date and what is not.
> Yeah, it's poor, but without extending JSON, what can be done?

It's problem if you want to write something like excel for arbitrary
JSON objects. Otherwise there is always agreement on a schema ahead of
time. Maybe dates should serialize as quoted ISO8601 strings by
default.

--

Robert Sayre

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

P T Withington
In reply to this post by Brendan Eich-2
Are the purveyors of JSON are familiar with the evolution of Lisp's  
print/read into make-load-form?

http://www.lisp.org/HyperSpec/Body/stagenfun_make-load-form.html#make- 
load-form

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Bob Ippolito
In reply to this post by Brendan Eich-2
On 10/20/06, Brendan Eich <[hidden email]> wrote:

> On Oct 20, 2006, at 3:51 PM, Bob Ippolito wrote:
>
> > On 10/20/06, Brendan Eich <[hidden email]> wrote:
> >> On Oct 20, 2006, at 3:36 PM, Erik Arvidsson wrote:
> >>
> >> > If Date is serialized as an ISO strings the process of encoding and
> >> > decoding loses information. If Dates are added to JSON then they
> >> > should be encoded using new Date(ms). However Dates are not
> >> supported
> >> > in JSON today and removing them from JS2 seems OK.
> >>
> >> ES4 also standardizes Date.parse to accept the same ISO 8601 date
> >> strings, so I don't believe any information is lost.
> >
> > Even if there wasn't, you can always turn strings into dates the hard
> > way as MochiKit does...
>
> Sure.  That was more an FYI (ECMA-262 left Date.parse unspecified, a
> botch that requires browsers to reverse engineer IE JScript's
> Date.parse implementation).
>
> > The important part is that the metadata that it is a date is lost,
> > even if there's an easy way to make dates from strings. You have to
> > know which strings should be treated as dates.
>
> You're right, but JSON does not provide any way to distinguish this
> case (preserve the bit of metadata you cite).
>
> >> You're right that this automatic encoding of Date objects as ISO
> >> strings does not result, when decoding, in Date objects again.
> >> Fixing that would require a pass over the decoded structure, or a use
> >> of the optional object hook on the enclosing object.  Is this a
> >> problem?
> >
> > The object hook would be no good here because it would have to be able
> > to find ISO strings by key (or regexing all string values looking for
> > dates.. bleh).
>
> The context would have to determine what's a date and what is not.
> Yeah, it's poor, but without extending JSON, what can be done?

The encoder should have an object hook the same way the decoder does.
Throw away the filter.

You'd have an encoder hook that knows how to turn a Date object into
some specific object representation, and a decoder hook that does the
inverse. Then you could use the JSON encoder to encode whatever you
wanted into a valid JSON document however it needed to be laid out.

Filtering functionality can be implemented if necessary by writing an
encoder hook that inspects the object. If it needs to remove some
key:value pairs, then it would create a new object that is missing the
keys that should be filtered.

-bob

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

John Cowan
In reply to this post by Brendan Eich-2
Brendan Eich scripsit:

>     * cannot be encoded as valid JSON (such as a function,  
> undefined, and NaN)

I think NaN is a place where there should be some pushback; there is
no reason why JSON should not implement NaN, perhaps in the form +nan
or +0.nan .

--
A mosquito cried out in his pain,               John Cowan
"A chemist has poisoned my brain!"              http://www.ccil.org/~cowan
        The cause of his sorrow                 [hidden email]
        Was para-dichloro-
Diphenyltrichloroethane.                                (aka DDT)

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
In reply to this post by Bob Ippolito
On Oct 20, 2006, at 4:11 PM, Bob Ippolito wrote:

> The encoder should have an object hook the same way the decoder does.

Symmetry, what a good idea.  TG1 members should consider this seriously.

> Throw away the filter.

There was some desire to filter without copying.

> Filtering functionality can be implemented if necessary by writing an
> encoder hook that inspects the object. If it needs to remove some
> key:value pairs, then it would create a new object that is missing the
> keys that should be filtered.

That's the copy we hoped to avoid.  Not a problem in your simplejson  
experience?

/be


Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
In reply to this post by John Cowan
On Oct 20, 2006, at 4:15 PM, John Cowan wrote:

> Brendan Eich scripsit:
>
>>     * cannot be encoded as valid JSON (such as a function,
>> undefined, and NaN)
>
> I think NaN is a place where there should be some pushback; there is
> no reason why JSON should not implement NaN, perhaps in the form +nan
> or +0.nan .

Doug is on this list, but the RFC is published and we are not the  
group to evolve it.  So for ES4 we are not going beyond what's in the  
JSON RFC.

/be


Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Bob Ippolito
In reply to this post by Brendan Eich-2
On 10/20/06, Brendan Eich <[hidden email]> wrote:
> On Oct 20, 2006, at 4:11 PM, Bob Ippolito wrote:
>
> > The encoder should have an object hook the same way the decoder does.
>
> Symmetry, what a good idea.  TG1 members should consider this seriously.
>
> > Throw away the filter.
>
> There was some desire to filter without copying.

What was the use case for filtering? I've never seen anyone do that.

> > Filtering functionality can be implemented if necessary by writing an
> > encoder hook that inspects the object. If it needs to remove some
> > key:value pairs, then it would create a new object that is missing the
> > keys that should be filtered.
>
> That's the copy we hoped to avoid.  Not a problem in your simplejson
> experience?

Not a problem because I've never seen anyone perform such a filter. If
the output needs to differ from the input it's usually based on the
*value* not the key:value pair. When the encoding needs to differ it's
usually not strict subset of the input, but a different object
altogether.

-bob

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
On Oct 20, 2006, at 4:35 PM, Bob Ippolito wrote:

> On 10/20/06, Brendan Eich <[hidden email]> wrote:
>> On Oct 20, 2006, at 4:11 PM, Bob Ippolito wrote:
>>
>> > The encoder should have an object hook the same way the decoder  
>> does.
>>
>> Symmetry, what a good idea.  TG1 members should consider this  
>> seriously.
>>
>> > Throw away the filter.
>>
>> There was some desire to filter without copying.
>
> What was the use case for filtering? I've never seen anyone do that.

The use case is taking a vanilla object that may have ad-hoc  
properties that should not be serialized.  The filter could be used  
to whitelist or blacklist properties.

>> > Filtering functionality can be implemented if necessary by  
>> writing an
>> > encoder hook that inspects the object. If it needs to remove some
>> > key:value pairs, then it would create a new object that is  
>> missing the
>> > keys that should be filtered.
>>
>> That's the copy we hoped to avoid.  Not a problem in your simplejson
>> experience?
>
> Not a problem because I've never seen anyone perform such a filter. If
> the output needs to differ from the input it's usually based on the
> *value* not the key:value pair. When the encoding needs to differ it's
> usually not strict subset of the input, but a different object
> altogether.

Ok, good feedback.  TG1 (or at least yours truly) will take it to heart.

/be


Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Bob Ippolito
On 10/20/06, Brendan Eich <[hidden email]> wrote:

> On Oct 20, 2006, at 4:35 PM, Bob Ippolito wrote:
>
> > On 10/20/06, Brendan Eich <[hidden email]> wrote:
> >> On Oct 20, 2006, at 4:11 PM, Bob Ippolito wrote:
> >>
> >> > The encoder should have an object hook the same way the decoder
> >> does.
> >>
> >> Symmetry, what a good idea.  TG1 members should consider this
> >> seriously.
> >>
> >> > Throw away the filter.
> >>
> >> There was some desire to filter without copying.
> >
> > What was the use case for filtering? I've never seen anyone do that.
>
> The use case is taking a vanilla object that may have ad-hoc
> properties that should not be serialized.  The filter could be used
> to whitelist or blacklist properties.
>

That sounds mostly like hand-waving... I don't think that actually
happens in a way where the filter function would really help out.

Also, the idea that the filter function should be done without copying
is kinda silly. Is it faster to make N function calls (returning false
M times), or to make 1 function call that copies an object with N-M
key:value pairs (only when M>0)?

I'd imagine that for most values of N and M, that the latter is
better. When M is zero, which is probably usually will be, then there
is no copy made. It also provides symmetry with decoding and is
infinitely more flexible and useful.

-bob

Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Brendan Eich-2
On Oct 20, 2006, at 4:53 PM, Bob Ippolito wrote:

> I'd imagine that for most values of N and M, that the latter is
> better. When M is zero, which is probably usually will be, then there
> is no copy made. It also provides symmetry with decoding and is
> infinitely more flexible and useful.

I agree it's many times better to have a symmetric object hook.  I  
was re-reading

http://svn.red-bean.com/bob/simplejson/trunk/docs/module- 
simplejson.html#load

and wondered why you don't have an object hook for dump/dumps.  Also,  
is there a way to have the object_hook cause the key/value for which  
the object passed into the hook is the value to be skipped entirely?

You have infinitely more JSON encoding and decoding experience than I  
do (and I mean that mathematically ;-).  Any more rationale on the  
design decisions that you'd be willing to share here would be helpful.

/be


Reply | Threaded
Open this post in threaded view
|

Re: JSON decoding

Bob Ippolito
On 10/20/06, Brendan Eich <[hidden email]> wrote:

> On Oct 20, 2006, at 4:53 PM, Bob Ippolito wrote:
>
> > I'd imagine that for most values of N and M, that the latter is
> > better. When M is zero, which is probably usually will be, then there
> > is no copy made. It also provides symmetry with decoding and is
> > infinitely more flexible and useful.
>
> I agree it's many times better to have a symmetric object hook.  I
> was re-reading
>
> http://svn.red-bean.com/bob/simplejson/trunk/docs/module-
> simplejson.html#load
>
> and wondered why you don't have an object hook for dump/dumps.  Also,
> is there a way to have the object_hook cause the key/value for which
> the object passed into the hook is the value to be skipped entirely?

It does have a hook, but it's a method not a parameter...

"""
To extend this to recognize other objects, subclass and implement a
.default() method with another method that returns a serializable
object for o if possible, otherwise it should call the superclass
implementation (to raise TypeError).
"""

The object hook gets just object values, not key:value pairs. If you
don't want a key:value pair included, return an object that does not
have that key:value pair.

If you worked only with key:value pairs, then you wouldn't be able to
hook elements of an Array... and that would be silly. It's also not
reasonable to implement skip for Arrays, because if they're used as a
tuple then you've changed the meaning of the Array. Skipping an object
wholesale is best done by returning a placeholder like null, but in
general most people implement encoders that raise exceptions if stuff
they don't want ends up in the object graph...

-bob

123