is ES4 getting too bloated?

[Garrett Smith]

On 10/21/07, Brendan Eich <brendan at mozilla.org> wrote:
> I know of two industry-scale implementations under way, in addition
> to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all
> implementing ES4 in the next six to nine months. There's no reason,
> zero, apart from will to do something else, why Microsoft (which has
> enormous resources, in expert people and money) couldn't do likewise.
> Perhaps they yet will -- we don't really know what's coming in IE8 yet.
>
Ah, the old can't vs won't debate...

MS could have implemented position:fixed for Microsoft, could have
fixed a number of known bugs in JScript, et c.
>

 Give the overview at http://www.ecmascript.org/es4/spec/overview.pdf
> a read and let us know what you think.
>
"JSON JSON35 is a popular, lightweight, language-independent, textual
representation for structured data. It uses a
subset of ES3 literal syntax. ES4 provides serialization of data to
JSON format through the
toJSONString protocol and deserialization through the static method
string.parseJSON."

I think it is a bad idea.

I think it is not a critical feature.

String.prototype.parseJSON, returns an object. This is makes no sense.

The current proposal, Object.prototype.toJSONString, complicates
objects with responsibility that they should not necessarily have. It
will be easy to misuse. It will conflate Object.prototype with
implementation details possibly leaking into places they shouldn't.
Instead of keeping reduced access, it maximizes access. It does not
allow the functionality to be tested and debugged independently.

If these features go in the language, implementations and library
authors will be required to handle this method for all objects, of any
type, forever. The change will be permanent and intractable.

This feature is not critical; it can be added at any time. The flip
side to that is that once added, it cannot be removed. ever.

There are other possible ways JSON could be integrated into the language.

 * JSON could be a host object, something like the XML object.

 * A built in JSON object

A built in JSON object would keep the JSON serialization/parsing
independent. It will be easy to learn, easy to extend, easy to read
and maintain code that uses it, and it will fulfill the requirements.
It won't complicate Object.prototype.

JSON.parseFromString( s );
JSON.toJSONString( jsonObject, pretty );
	

 * A JSON Interface

A JSON interface can be implemented to allow a class to have the JSON
Methods as instance methods.

function parseFromString( s, pretty ) : <T>
function toJSONString( );
	
Test this out with three different types, say: Object, Map, and Array.

Also, If JSON is in the langauge, there would probably need to be some
sort of JSONError Error object.

Garrett

> /be
>


-- 
Programming is a collaborative art.