Re: Current JSON Proposal in ES4

On Oct 22, 4:01 pm, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
wrote:
dhtmlkitc...@xxxxxxxxx wrote:
On Oct 22, 12:33 am, Richard Cornford wrote:
dhtmlkitc...@xxxxxxxxx wrote:


<snip>

Integer.parseInt <-- what should this return?

No such construct exists in javascript as there is no Integer object
and - parseInt - is a global function.

The example was taken from Java, to illustrate the concept that
XXX.parse is usually expected to return an XXX.

parseInt should be a Number function, not global.parseInt.

Number.parseInt

BTW, global is accessible in ES4.


Date.parse <-- what should this return?

A 'static' method of the Date constructor might be expected to return
something that was date related.

Like a date string? A Number? How about...

A Date ?

Ding, ding, ding!

now,
String.parseJSON <-- should return what, a String?

Wasn't it - String.prototype.parseJSON - that you were objecting to? An
instance method of String object might be executed to turn that string
into anything. As JSON is a structure consisting of and object or array
with optional nested descendants then that is the likely result.

Why is adding the parse method to String correct?

Should the String constructor be morphed into a parser?


The current proposal, Object.prototype.toJSONString,
complicates objects with responsibility that they
should not necessarily have.

Why shouldn't an object have a specialised serialisation
method?

Why should it?

Precedence would be a good enough reason, as JavaScript(tm) already
has - toSource - method on objects. All this adds is another form of
serialisation, and one that has obvious practical applications.

JavaScript -- not ES. It's a really old feature, and only Moz/NS4.

While the feature may have practical applications, such applications
are quite limited. Limited to what? Well, mostly to Data Structure.
Object should not always have data structure functionality. Only data
structures should. A Menu, could, for example, be converted to a Data
Structure, or could be so implemented. This would be a design
decision.


If it needs one, it can get it independently.

Maybe, but not a native code (so relatively fast) method.

It could define it's own
method for serialization. Not all objects need this.

Much as objects don't need - toSource - but don't suffer for having it.

toSource is limited to Spidermonkey, AFAIK.

toJSONString will be an ES4 standard.

It will be easy to misuse.

An example of this "misuse"?

HTMLInputElement.prototype.toJSONString = getPWD;

There is plenty of scope for doing stupid things with the language as it
is.

Exactly! JavaScript lets you do all sorts of things.

"foo".prop
new Script("true");

"foo".big();

So why add another? And besides, toJSONString would be really useful
in a lot of cases. I realize that, really. But, at the same time, I
don't need it on my Tooltip.


Any of the misuses of for-in loop, or closures
would seem not as bad.

Which misuses?

Like the Power Constructor, the Module pattern. These things can and
are often used to make really strange and confusing code. There are
plenty of F/E devs who struggle trying to apply OO concepts to JS and
make judgement calls that create problems down the road.



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 unretractable.

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 many assertions here but not one substantial
argument to back any of them up. Between ECMA 262 2nd
edition and 3rd edition the object prototype gained
hasOwnProperty, propertyIsEnumerable and isPrototypeOf
methods with no negative impact. Adding methods to the
object prototype does not necessarily have any impact
on anything else at all.

propertyIsEnumerable attempts, but fails in addressing the
problem of determining if a property is enumerable. It is
broken, as defined by ECMA-262.

You have said that before, but still have not posted any demonstration
of this supposed brokenness.


function b() {}
b.prototype.pie = "yes"; // enumerable prop.

var i = new b;
i.propertyIsEnumerable('pie'); // Well, what do you think?
for(var prop in i)
alert(prop); // will it alert "pie"?

What went wrong?

propertyIsEnumerable does not check the prototype chain, but for-in
does.

That is a bug.


The JScript bug eliminates any possibility of this method
being suitable for cross-browser use.

Which JScript bug? The one where - dontEnum - attributes are inherited
through the prototype chain when they should not be?
Yes, well, *mostly* the bug itelf is incosistent.

({prototype:1}).propertyIsEnumerable('prototype'); // well, what does
JScript think?

(Function()).propertyIsEnumerable('prototype'); // well, what does
JScript think?


Objects need to deal with enumeration;
they're stuck with this
responsibility. This is is a problem.

It is not a problem. It has never been feasible to directly use
javascript objects as storage faculties for mapping arbitrary string
keys to values. The 'safe' set of possible keys in such a context don't
suffer from enumeration issues even in IE browsers.

All JScript bugs aside, Object is a generic type. HashMap, or
Map<String,Object>, is specific. It says: I'm a data structure.


isPrototypeOf is useless/harmless. Can't be removed,
though.

As useless/irrelevant as - instanceof -.

Well, instanceof was there first. In ES4, it will work across frames.


toJSONString would not be so benign.

Why not, it would do no harm if not used, and if used then there would
presumably be some reason for using it.

It will be used. A lot, I think.

It's almost as bad is Object enumeration.

What is "bad" about object enumeration?

Enumeration has nothing to do with Object as a type. The feature
causes problems that have been the topic of discussion for years.


Or maybe worse. It means that every object is, by
default, not just a data structure, but a data structure that
also supports a specialized (or default) serialization.

Which is already the reality for JavaScript(tm) and that doesn't seem to
have resulted in any problems.

I've had my share of problems with this. Mostly related to the JScript
bug.

How in any way, is it justified?

Expedience, in the face of a growing use of JSON as a data exchange
medium, and particularly for transmission between HTTP clients and
servers.

JSON is not the panacea, for those who think it is, a native JSON
object will provide the same functionality, and will do nothing other
than provide such functionality.


Maybe 2% of all objects will need serialization at most.

Maybe, maybe not. What of it, I don't thing I have ever used
propertyIsEnumerable in production code but no objects have suffered for
having that unused method?

Besides being misnamed propertyIsEnumerable is broken.

for example:

x.toJSONString();

if x is an instance of

function Widget() {
_name : "widget_" + widget.instances.length;
}

Well, then you have to filter out the _name property in your
serialize method.

Why? What is it doing there if you don't want it included in the
serialisation, or if you don't want it why use the prototype
toJSONString method? You are the one doing the programming so program
the system to be what you want it to be.

Because it means that by default, Widget MUST tackle this
responsibility. Widget is Serializable, even if I don't want it to be,
I, as a programmer, have had that right taken away. That sucks.


Alternatives

1. A built in JSON object

Because JSON translates directly into structures of javascript
objects/arrays it makes no sense to attempt to create a specific
JSON object.

JSON is a subset of JavaScript

Yes, a restriction of the nature of property name declarations in the
object literal strings and the types of values that may be assigned to
properties.

JSON translates into JS structures.

Which is what we are doing, taking a JSON string and getting a
javascript object.

JS Structures do not translate to JSON.

They can (or the whole thing would be a non-starter). All you are saying
is that objects can be created that will not translate well. And they
can, but that does not mean that rational programmers will create such
objects.

A Tooltip.show() method seems pretty rational to me. What does that
have to do with data structures?


It is not justified in ES3.

Adding serialization capabilities to every object creates
unnecessary complications. Each type of object has to deal
with this.

More like the serialisation process has to be able to deal with (in some
predetermined manner) all possible javascript objects. But that is just
a mater of specification.

Exactly. The serialization has to, and if it doesn't the programmer
has to provide it.

I can see it now, people will want next a way to set a serializable
flag on their properties to make things easier.

How would you serialize a Callable, a subclassed string,
an HTMLInputElement?

HTMLInputElement are not required to have prototype chins or inherit
form Object.protoype so they are irrelevant in the general case. Other
objects have properties with attributes and values regardless of their
'type'.

Not required, but they do, in many browsers. In those cases, it will
be required to deal with serialization.


And Callable is an Object, and a subc'd String is a String.

How is any of the above justified?

How is adding JSON methods to all objects justified over adding a
separate Class/Object to handle serialization?

<snip>

How is any of what justified? The proposed methods are an expedient or
harmless addition to the group of methods already on the pertinent
prototypes.

Not harmless when my Tooltip has to be responsible for serializing
itself.

Before having a JSON class implemented, I'd like to see three basic
types supported by a JSON object (like Map, et c).

a JSON Object would do:
serialize
deserialize

For those interested, Robert Sayre is implementing some JSON object
support in Mozilla, something along the lines of Caja.

Garrett

Richard.


.

Relevant Pages

  • Re: How Do I Create Nested JSON Objects for Serialization (Using My JsonHelper Class)?
    ... >> nested fields using the JsonHelper for serialization? ... JSONHelper class so I can serialize a JSON object within a JSON object ... Public class Category ... Public string ID ...
    (microsoft.public.dotnet.languages.csharp)
  • How Do I Create Nested JSON Objects for Serialization (Using My JsonHelper Class)?
    ... I am using the below jsonHelper class ... public static string Serialize ... public static T Deserialize(string json) ... nested fields using the JsonHelper for serialization? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: XmlSerializer Collection with Collections
    ... What you can do here is hide the OptionList from serialization as follows: ... > public class TestSerializer ... > public int AddQuestion(Question question) ... > public Question(string QuestionText, string Type, int Score, bool ...
    (microsoft.public.dotnet.xml)
  • Re: Serializing/Deserializing to Database
    ... into string, such as base64 convertion). ... private void btnDeserialize_Click ... MySavableClass msc = obj as MySavableClass; ... serialization for further reference: ...
    (microsoft.public.dotnet.framework)
  • Re: Current JSON Proposal in ES4
    ... This is very poor design. ... given that part of the point of JSON is that it can be directly ... supports a specialized serialization. ... Because JSON translates directly into structures of javascript ...
    (comp.lang.javascript)