Current JSON Proposal in ES4

[dhtmlkitchen]

JSON
We all know what it is.

In ECMAScript 4, there's a JSON proposal:

Object.prototype.toJSONString
String.prototype.parseJSON
The current proposal, String.prototype.parseJSON, returns an object.
This is very poor design. It's worse than Date.parse(s), which returns
a Number (not a Date).

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

1. 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 );
2. 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( );
An JSON interface could instead be simply a tagging interface.
If the object supports the JSON interface, it could be used with a
JSON static JSON.parseFromString( s, type );, where type is something
like Map.

Test this out with three different types, say: Object, Map, and
Array.

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

[Richard Cornford]

<dh**********@gmail.comwrote:

JSON
We all know what it is.

A subset of javascript's Object/Array literal notation used for data
representation/exchange.

In ECMAScript 4, there's a JSON proposal:

Object.prototype.toJSONString
String.prototype.parseJSON
The current proposal, String.prototype.parseJSON, returns an
object. This is very poor design. It's worse than
Date.parse(s), which returns a Number (not a Date).

Why, given that part of the point of JSON is that it can be directly
translated into object structures in jvascrtip?

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?

It will be easy to misuse.

An example of this "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 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.

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.

<snip>

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

A JAON parsing error seems appropriate, though javascript's errors need
a great deal of additional work before they become that usable.

Richard.

[Thomas 'PointedEars' Lahn]

dh**********@gmail.com wrote:

In ECMAScript 4, there's a JSON proposal:

Object.prototype.toJSONString
String.prototype.parseJSON

Good idea.

The current proposal, String.prototype.parseJSON, returns an object.
This is very poor design.

IBTD. As JSON is a subset of Object/Array literal notation, I don't see a
reason why the result should *not* be an object.

It's worse than Date.parse(s), which returns a Number (not a Date).

Date.parse(s) is more flexible than it would be if it returned a Date object
reference. If the number bothers you, you are free to use `new Date(s)'
instead or use the return value of Date.parse(s) as argument for the
constructor.

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.

Why would that be? Those will be built-in methods then, and most certainly
they will have the DontEnum attribute.

Instead of keeping reduced access, it maximizes access.

More important is that such methods would finally provide efficient
implementation-independent means.

It does not allow the functionality to be tested and debugged independently.

Did you care to debug toString(), toValue() aso. to date?

[...]
An JSON interface could instead be simply a tagging interface.
If the object supports the JSON interface, it could be used with a
JSON static JSON.parseFromString( s, type );, where type is something
like Map.

Test this out with three different types, say: Object, Map, and
Array.

Please forgive my ignorance, what would Map be?

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

That would be useful, but not necessary.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[dhtmlkitchen]

On Oct 22, 10:49 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

[e-mail] wrote:

In ECMAScript 4, there's a JSON proposal:

Object.prototype.toJSONString
String.prototype.parseJSON

Good idea.

The current proposal, String.prototype.parseJSON, returns an object.
This is very poor design.

IBTD. As JSON is a subset of Object/Array literal notation, I don't see a
reason why the result should *not* be an object.

Objects are used for collections. There are no other collection types
in ES3.

Objects are used for other things than collections, most of the time.

The conflation of Object and Hashtable causes problems in ES. Adding
toJSONString further complicates Objects with more responsibility.

It's worse than Date.parse(s), which returns a Number (not a Date).

Date.parse(s) is more flexible than it would be if it returned a Date object
reference. If the number bothers you, you are free to use `new Date(s)'
instead or use the return value of Date.parse(s) as argument for the
constructor.

The return type is incorrect. Even in Java's Date object (which has
it's problems) Date.parse returns a Date (normal). The problem is that
you can't parse localized dates based on a string. It's impossible.

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.

Why would that be? Those will be built-in methods then, and most certainly
they will have the DontEnum attribute.

W/A JSON Object, You could add it yourself w/only a few lines of code:

unit ThomasJSON {
internal package ThomasJSON {
Object.prototype.toJSONString = function () { return
JSON.toJSONString(this) };
Object.prototype.propertyIsEnumerable("toJSONStrin g", false);
}
}

In your code:

use unit ThomasJSON "http://example.com";

Instead of keeping reduced access, it maximizes access.

More important is that such methods would finally provide efficient
implementation-independent means.

It does not allow the functionality to be tested and debugged independently.

Did you care to debug toString(), toValue() aso. to date?

What is aso?

valueOf should produce testable, consistent results on Date objects

Date.prototype.toString providing a formatting dependency is a
problem. It is not localized.

toDateString and toTimeString should be on a DateFormatter class.

toString should be for diagnostic info.

[...]
An JSON interface could instead be simply a tagging interface.
If the object supports the JSON interface, it could be used with a
JSON static JSON.parseFromString( s, type );, where type is something
like Map.

Test this out with three different types, say: Object, Map, and
Array.

Please forgive my ignorance, what would Map be?

Map<T,Tis a data structure. It's in ES4. Long overdue.

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

That would be useful, but not necessary.

Depends what 'necessary' means. A lot of necessary things
(collections) are missing in ES3, yet we manage.

Constructor's based on Error (subclass) in ES3 doesn't really work
that well.

PointedEars

[Peter Michaux]

On Oct 22, 3:09 pm, "[e-mail]" <[e-mail]>
wrote:

Objects are used for collections. There are no other collection types
in ES3.

Objects are used for other things than collections, most of the time.

The conflation of Object and Hashtable causes problems in ES.

In all completely object-oriented languages, like JavaScript, isn't it
necessary that hashes are objects?

Adding
toJSONString further complicates Objects with more responsibility.

If the line of purity has already been crossed, and objects have more
responsibilities than they should, what exactly is _so_ offensive with
one more? That is meant as a genuine question. Will the existence of
the toJSONString property make day-to-day programming with JavaScript
more difficult or different than it is now?

unit ThomasJSON {

Is "unit" a new keyword for ES4?

Map<T,Tis a data structure. It's in ES4. Long overdue.

Is the "<T,T>" optional for those that don't want to use types?

We are really headed towards Java, aren't we? The sad thing is some
poor JavaScript programmers, who don't want to program in Java, are
going to be told to program the Java way once ES4 is available.

Peter

[Richard Cornford]

Peter Michaux wrote:

On Oct 22, 3:09 pm, "[e-mail]" wrote:

<snip>

>unit ThomasJSON {

Is "unit" a new keyword for ES4?

And say goodbye to any hope of back-compatibility with current versions
if it is, as up until now "unit" had been a valid Identifier, and one I
use quite often as I use JS object reprehensions of commercial
buildings, which are sub-divided into units.

We are going to end up with another MIME type hack here.

>Map<T,Tis a data structure. It's in ES4. Long
overdue.

Is the "<T,T>" optional for those that don't want to
use types?

We are really headed towards Java, aren't we?

Unfortunately it has looked that way for some time. Java already exists
so I don't see the point in trying to create another. And it is a near
certainty that the end result actually will be the inferior Java that
javascript is already often mistakenly perceived as being.

The sad thing is some poor JavaScript programmers, who
don't want to program in Java, are going to be told to
program the Java way once ES4 is available.

What makes you think ES4 will offer the choice?

Richard.

[dhtmlkitchen]

On Oct 22, 4:10 pm, Peter Michaux <[e-mail]:

On Oct 22, 3:09 pm, "[e-mail]" <[e-mail]>
wrote:

Objects are used for collections. There are no other collection types
in ES3.

Objects are used for other things than collections, most of the time.

The conflation of Object and Hashtable causes problems in ES.

In all completely object-oriented languages, like JavaScript, isn't it
necessary that hashes are objects?

A HashMap is an Object, an Object is not a HashMap. An object might be
a Menu. A Menu is not a HashMap. Too much responsibility for a Menu.
It violates most general programming principles like cohesion, SRP. It
is a problem with the ES3-.

Adding
toJSONString further complicates Objects with more responsibility.

If the line of purity has already been crossed, and objects have more
responsibilities than they should, what exactly is _so_ offensive with
one more? That is meant as a genuine question. Will the existence of
the toJSONString property make day-to-day programming with JavaScript
more difficult or different than it is now?

Getting away from object as a hashtable is the right direction.

unit ThomasJSON {

Is "unit" a new keyword for ES4?

Map<T,Tis a data structure. It's in ES4. Long overdue.

Is the "<T,T>" optional for those that don't want to use types?

Not optional, however,

<Object,Object>

- or -

<String,Object>

We are really headed towards Java, aren't we? The sad thing is some
poor JavaScript programmers, who don't want to program in Java, are
going to be told to program the Java way once ES4 is available.

That is false.

ES4 is backwards compatible.

Peter

[Peter Michaux]

On Oct 22, 6:03 pm, "[e-mail]" <[e-mail]>
wrote:

On Oct 22, 4:10 pm, Peter Michaux <[e-mail]:On Oct 22, 3:09 pm, "[e-mail]" <[e-mail]>

We are really headed towards Java, aren't we? The sad thing is some
poor JavaScript programmers, who don't want to program in Java, are
going to be told to program the Java way once ES4 is available.

That is false.

ES4 is backwards compatible.

I meant told by their managers, not by the ES4 spec writers.

Peter

[dhtmlkitchen]

On Oct 22, 4:01 pm, "Richard Cornford" <[e-mail]>
wrote:

[e-mail] wrote:

On Oct 22, 12:33 am, Richard Cornford wrote:

[e-mail] 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.

[Peter Michaux]

On Oct 22, 7:08 pm, "[e-mail]" <[e-mail]>
wrote:

[snip about propertyIsEnumerable bug]

[snip about IE for-in enumeration bug]

[snip about object enumeration is a bad idea]

[snip about object serialization should not be an object property]

[snip about propertyIsEnumerable bug]

[snip about propertyIsEnumerable bug]

[snip about object serialization should not be an object property]

[snip about object enumeration is a bad idea]

[snip about IE for-in enumeration bug]

[snip about object serialization should not be an object property]

[snip about IE for-in enumeration bug]

[snip about object enumeration is a bad idea]
It's starting to be a ball of confusion which are the real problem
that need fixing and which are stylistic "separation of concerns"
issues. Your recommendations for ES3 to ES4 change have not been
separated. ;-) The real problems need the most attention. Consensus
will likely not be reached on stylistic issues.

I can see that the propertyIsEnumerable and the IE for-in bug seem to
be legitimate problems.

I've never had a problem with the for-in loop. I suppose that means
that when using an object as a hash that is subsequently enumerated
with for-in in IE, I have never added a "prototype" hash key. Is that
what this boils down to? This definitely seems to be something that
should be fixed.

It may be that most people don't really care if parseJSON is a
property of String or String.prototype or some JSON object. I know
that for functionality like serialization I care most that the
implementations work as specified. The JavaScript language is
considered by most to be a mess and there is no chance of attaining
any purity so where the JSON functions live is not so important to me.
If API structure was something that I allowed to bother me daily I'd
have popped by now working with JavaScript.

I definitely recommend dropping your recommended change from
propertyIsEnumerable to isPropertyEnumerable. If the target is moving,
the browser makers will never all hit it at the same time or ever.
This naming issue is completely superficial and detracts from other
more important and numerous recommendations perhaps to the point that
all recommendations will be ignored.

Peter

[Dr J R Stockton]

In comp.lang.javascript message <11**********************@q5g2000prf.goo
glegroups.com>, Mon, 22 Oct 2007 22:09:19, "dh**********@gmail.com"
<dh**********@gmail.composted:

>The return type is incorrect. Even in Java's Date object (which has
it's problems) Date.parse returns a Date (normal). The problem is that
you can't parse localized dates based on a string. It's impossible.

You can do it in javascript if the localisation is known, by first using
RegExp replace to convert all-numeric dates to YYYY/MM/DD and if
necessary to convert YY to YYYY. And to translate months to English.

In future, new Date(String) could be enhanced to recognise roman
numerals for months. I've seen evidence suggesting that some Europeans
like that.

That does not, however, accommodate non-Gregorian localisations.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[dhtmlkitchen]

On Oct 22, 8:23 pm, Peter Michaux <[e-mail]:

On Oct 22, 7:08 pm, "[e-mail]" <[e-mail]>
wrote:

[snip about propertyIsEnumerable bug]

[snip about IE for-in enumeration bug]

[snip about object enumeration is a bad idea]

[snip about object serialization should not be an object property]

[snip about propertyIsEnumerable bug]

[snip about propertyIsEnumerable bug]

[snip about object serialization should not be an object property]

[snip about object enumeration is a bad idea]

[snip about IE for-in enumeration bug]

[snip about object serialization should not be an object property]

[snip about IE for-in enumeration bug]

[snip about object enumeration is a bad idea]

It's starting to be a ball of confusion which are the real problem
that need fixing and which are stylistic "separation of concerns"
issues. Your recommendations for ES3 to ES4 change have not been
separated. ;-) The real problems need the most attention. Consensus
will likely not be reached on stylistic issues.

What are the most important things then?

I can see that the propertyIsEnumerable and the IE for-in bug seem to
be legitimate problems.

I've never had a problem with the for-in loop.

I have. I use toString and valueOf fairly often, so it gets to be a
problem in IE because IE skips those (and others).

I suppose that means

that when using an object as a hash that is subsequently enumerated
with for-in in IE, I have never added a "prototype" hash key. Is that
what this boils down to? This definitely seems to be something that
should be fixed.

No, what happens, in IE, is that IE will skip anything prop on an obj,
when a corresponding obj in the prototype chain has DontEnum. IE does
not skip a property named "prototype", well, unless it's a function.
aFunction.prototype would be enumerable.
[snip about parseJSON]

>
I definitely recommend dropping your recommended change from
propertyIsEnumerable to isPropertyEnumerable.

People get confused. I did, for a long time, I would write
"isPropertyEnumerable", then feel like an idiot when I got the error.
Webkit guys wanted a rename.

Flash DID rename propertyIsEnumerable. They've got an
isPropertyEnumerable method. From the looks of it, it does the same
thing.

If the target is moving,

the browser makers will never all hit it at the same time or ever.
This naming issue is completely superficial and detracts from other
more important and numerous recommendations perhaps to the point that
all recommendations will be ignored.

Yeah, it is not the most important thing. I agree, and in fact, even
if propertyIsEnumerable got fixed, it wouldn't have as significant an
impact on the language as a lot of the other stuff in ES4.

BTW, what ever happened to the partials idea?

Garrett

Peter

[Peter Michaux]

On Oct 23, 6:46 pm, "[e-mail]" <[e-mail]>
wrote:

On Oct 22, 8:23 pm, Peter Michaux <[e-mail]:

On Oct 22, 7:08 pm, "[e-mail]" <[e-mail]>
wrote:

It's starting to be a ball of confusion which are the real problem
that need fixing and which are stylistic "separation of concerns"
issues. Your recommendations for ES3 to ES4 change have not been
separated. ;-) The real problems need the most attention. Consensus
will likely not be reached on stylistic issues.

What are the most important things then?

I meant the more important stuff you were talking about. It seems like
some issues you've been talking about lately are far more important
than others. The for-in crap in IE sounds like a big problem that
needs fixing. I've been fortunate enough to avoid simply by accident.
Fortunately I don't have any objects with user supplied property names
that are then enumerated. I can see that as the biggest problem.

The standard really should have a readable/writable __proto__
property. I think the clone() business would be good. More stuff to
support prototype-based inheritance.

[snip]

BTW, what ever happened to the partials idea?

Nothing I guess. It is in the ES4 wiki on the page about generics. I'm
not so keen on ES4 and didn't push the idea heavily. Seems to me like
the ES4 group has "given up the good fight" in favor of appeasing the
masses with their types and classes. That's ok since the masses are
very big and do complain loudly. JS3 is going to be the really good
one: macros and some sort of erlang-like thread deal. I'll be very
happy to play with macros. I suppose it will be in about 2025,
however :)

Peter

[dhtmlkitchen]

On Oct 22, 4:51 pm, "Richard Cornford" <[e-mail]>
wrote:

Peter Michaux wrote:

On Oct 22, 3:09 pm, "[e-mail]" wrote:

<snip>

unit ThomasJSON {

Is "unit" a new keyword for ES4?

And say goodbye to any hope of back-compatibility with current versions
if it is, as up until now "unit" had been a valid Identifier, and one I
use quite often as I use JS object reprehensions of commercial
buildings, which are sub-divided into units.

You can bring this up on the ES4 list. It would be a problem if you
could not do, say,

var unit = 'blah';

>
Richard.

[Thomas 'PointedEars' Lahn]

dh**********@gmail.com wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

>[...]

Further full-quoting will lead to your being added to my killfile.

>>>>>Test this out with three different types, say: Object, Map, and
>Array.
Please forgive my ignorance, what would Map be?
Map<T,Tis a data structure. It's in ES4.

No, it's not. Map as used in subsection 5.2.1 of the current ES4 draft is
purely a specification mechanism, not a language feature:

No, there's really a Map! It's a new built-in.

The overview.pdf is here:
http://www.ecmascript.org/docs.php

It's a pretty easy read, so good for those who want a quick overview.

You have yet to understand that there are proposals for the future
specification, and there is a specification text that has been agreed on
already.

>| 12 Every program visible value is an object. An object is a collection of
| properties.
| 13
| 14 struct Object {
| 15 delegate : Object
| 16 properties : Map<Name,Object>
| 17 type : Traits
| 18 slots : List<Object>
| 19 }

>>Long overdue.

How can a type that can only exist with strict typing it be "long overdue"
if previous editions did not specify strict typing at all?

I don't know quite what you're asking.

The question was rhetorical of course. The designation "long overdue" for a
feature that could not exist before is inappropriate.

Do you mean Parameterized type, or strict mode?

Neither of those, whatever you may mean.

It's a useful construct, regardless.

We'll see. So far it is merely useful in the agreed-on text of the language
specification to explain the structure of objects.

>>>>If JSON is in the langauge, there will need to be some sort of
JSONError Error object.
That would be useful, but not necessary.
Depends what 'necessary' means. A lot of necessary things (collections)
are missing in ES3, yet we manage.
Constructor's based on Error (subclass) in ES3 doesn't really work that
well.

ES3 has no classes, but I would like ES4 to provide the possibility to
derive from Error to create my own error classes/prototypes. However,
another exception type is not necessary to handle JSON parsing errors.

ES4 will offer classes. [...]

You don't say!

I think you'll be able to extend built in Error.

One can only hope so.

I'm not sure about this, but you can try it in the reference impl,
on ecmascript.org.

The reference implementation is not the final version at this point.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Richard Cornford]

<dh**********@gmail.comwrote:

On Oct 22, 4:51 pm, Richard Cornford wrote:

>Peter Michaux wrote:

>>On Oct 22, 3:09 pm, "[e-mail]" wrote:

<snip>

>>>unit ThomasJSON {

>>Is "unit" a new keyword for ES4?

And say goodbye to any hope of back-compatibility with
current versions if it is, as up until now "unit" had
been a valid Identifier, ...

<snip>

You can bring this up on the ES4 list.

Why? Are the people on the "ES4 list" sufficiently ignorant of
ECMAScript that they don't know what an Identifier is?

It would be a problem if you
could not do, say,

var unit = 'blah';

It would also be a problem if you could not do:-

unit = 'blah';

- or:-

unit;

- or:-

unit

- as they are all legal constructs with well specified behaviour in
ECMAScript (even if the last two are useless).

One way out of that is to have considerably more complex syntax rules
for - unit - which force its interpretation as a keyword in some
contexts and as an identifier in others. But that hardly lends itself to
being easily understood by programmers.

Richard.

[Elegie]

Richard Cornford wrote :

Hi Richard,

<snip>

Indeed I well remember being surprised the first time I observed the
inline execution of a function expression back in November 2002:-

<URL:
http://groups.google.com/group/comp....da01126dd6ea8c

>

(That post may include the first example of the inline execution of a
function expression ever.

Hm, no, I think that the first javascript application of an inline
execution of a function expression was actually proposed by the
stereofrog, a.k.a Gosha Bine (who many times demonstrated expert
knowledge in several programming languages, including functional
languages), whose scripts I had studied while learning the language,
months before.

The post you cite, however, may very well be the first time I used
myself an inline execution of a function expression - and I was very
happy of this "getText" function :)

I would be interested in any examples
pre-dating that one,

Here's one link, March 1st, 2002.

<URL:http://groups.google.fr/group/comp.lang.javascript/msg/53a87649e279a012>
<OT>
That brings back very good memories, actually. I was then in Stockholm
practicing finance, and found myself very interested in javascript. I
rushed on all the technical specifications I could grasp, and started
participating actively in the group.

At the time, I systematically scrutinized the answers of Jim Ley, Martin
Honnen and Gosha Bine. Gosha Bine, especially, had an incredible style;
his answers were always technically correct, and *simple* (the kind of
simplicity a true expert displays when talking about his knowledge).

I printed all the scripts he proposed on his website, then started to
try and understand the gems, always on the last night bus that would
take me home - and the driver, the same tired man every night, would
always shake his head about this young guy reading strange pieces of
paper...

I definitely owe my coding style to Gosha's scripts - except for the
simplicity, but that's certainly because I never was as expert as he was.
</OT>

Anyway, it's very nice to read you again, I hope you, and every other
'old' regulars of the group, are doing fine. Take care, and see you.
Regards,
Yep.

PS : sorry for the delay of the correction; I happened to read this post
only today (as I was researching a certain piece of code in some of my
older posts).

[Thomas 'PointedEars' Lahn]

dh**********@gmail.com wrote:

On Oct 27, 2:28 pm, "Richard Cornford" <[e-mail]>
wrote:

><[e-mail]:

>>On Oct 22, 4:01 pm, Richard Cornford wrote:
[e-mail] wrote:
On Oct 22, 12:33 am, Richard Cornford wrote:
>[e-mail] wrote:
<snip>

<snip>

>If three is one running theme in your posts to this group it is that
your expectations don't match up very well with javascript.

I don't really think JavaScript was well designed. toString, for
example, should not be relied upon (OT) but ES requires it for many
methods, and even defines, in many cases, the implementation for
toString.

What are you talking about? ES3 does not specify algorithms that depend or
rely upon ToString() return values. It defines the implementation for
ToString() and for the toString() method of built-in objects, and rightly so.

That does not mean the toString() method could not be overwritten; it can,
and the resulting property appears to retain its DontEnum attribute (tested
with Firebug only):

function strRepeat(s, n)
{
if (n < 0) n = 0;

var a = [];

while (n--) a.push(s);

return a.join("");
}

Object.prototype.toString = function(level)
{
if (arguments.length < 1) level = 0;

var s = strRepeat(" ", level);
var a = [s + "{"];

for (var p in this)
{
a.push([
" ", s, p, ": ", this[p] && this[p].toString(level + 1)
].join(""));
}

a.push(s + "}");

return a.join("\n");
};

window.alert({foo: {bar: "baz"}});

ES4 has a lot of changes. For example 1 global object -- a headache
saver, IMO.

What do you mean? There is already only one Global Object since ES1,
and it can be referred to in the global execution context with `this'.

Please trim your quotes.

Finally, I'm really glad to see that the TG1 group has decided that
Object.prototype.toJSONString is out,

I'm not. It would have been a useful addition. Now we will have to
continue to include a larger and considerably slower library for that feature.

and have removed it from the ES4 spec.

Too bad.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[dhtmlkitchen]

On Nov 25, 3:31 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

[e-mail] wrote:

On Oct 27, 2:28 pm, "Richard Cornford" <[e-mail]>
wrote:

<[e-mail]:
On Oct 22, 4:01 pm, Richard Cornford wrote:
[e-mail] wrote:
On Oct 22, 12:33 am, Richard Cornford wrote:
[e-mail] wrote:
<snip>

<snip>

<snip about JS not being well-designed>

>
What are you talking about? ES3 does not specify algorithms that depend or
rely upon ToString() return values. It defines the implementation for
ToString() and for the toString() method of built-in objects, and rightly so.

Date.prototype.toString is defined to return something parseable by
parse()

Number.prototype.toString( radix ) -- also defined by the spec.

The API can't change these without breaking existing code.

That does not mean the toString() method could not be overwritten; it can,
and the resulting property appears to retain its DontEnum attribute (tested
with Firebug only):

That is true; a property's attributes are not changed when it's value
is replaced. Even JScript gets this right.

<snip of custom toString>

>

ES4 has a lot of changes. For example 1 global object -- a headache
saver, IMO.

What do you mean? There is already only one Global Object since ES1,
and it can be referred to in the global execution context with `this'.

if(top != self) {
// different global object.
}

The headaches come from trying to, for example, see if an object is an
Array.

function isArray( it ) {

}

The frames/windows issue is the part that makes it hard.

>
PointedEars

[Thomas 'PointedEars' Lahn]

dh**********@gmail.com wrote:

On Nov 25, 3:31 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>[e-mail] wrote:

>>On Oct 27, 2:28 pm, "Richard Cornford" <[e-mail]>
wrote:
<[e-mail]:
On Oct 22, 4:01 pm, Richard Cornford wrote:
>[e-mail] wrote:
>>On Oct 22, 12:33 am, Richard Cornford wrote:
>>>[e-mail] wrote:
<snip>
<snip>

<snip about JS not being well-designed>

>What are you talking about? ES3 does not specify algorithms that depend or
rely upon ToString() return values. It defines the implementation for
ToString() and for the toString() method of built-in objects, and rightly so.

Date.prototype.toString is defined to return something parseable by
parse()

That is a definition in the opposite direction than you implied.

Number.prototype.toString( radix ) -- also defined by the spec.

Again I don't see a definition that would rely on the return value of this
method.

The API can't change these without breaking existing code.

"The API", whatever you understand by that, does not need to change these.

>>ES4 has a lot of changes. For example 1 global object -- a headache
saver, IMO.

What do you mean? There is already only one Global Object since ES1,
and it can be referred to in the global execution context with `this'.

if(top != self) {
// different global object.
}

You are confusing the language and one of its possible runtime environments.
`top' and `self' are properties of a Window host object as provided by the
AOM. It makes sense that every global execution context has its own Global
Object, and I doubt ES4 is going to change that as that would make it
incompatible with current Web applications.

The headaches come from trying to, for example, see if an object is an
Array.

function isArray( it ) {

}

You are not making any sense.

The frames/windows issue is the part that makes it hard.

Which does not have anything to do with the programming language.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Richard Cornford]

<dh**********@gmail.comwrote:

On Oct 27, 2:28 pm, Richard Cornford wrote:

<snip>

>... "the Module pattern"

<snip>

>
Doug Crockford seems to be taking credit for this pattern.

I have never seen any evidence of his doing that. And I would be very
surprised if he did, mostly because I have always regarded him as having
too much intellectual integrity, but also because I know he is smart
enough to know that the historical record would not support such a
claim.

Other people may be crediting him with the invention, but those people
also seem to regard it as something new that can be subject to ongoing
development rather than being an idea that is nearly half a decade old
and has already seen the extensive examination of its possible
permutations and applications.

Still, just so we don't have to waste time disputing this here is the
history:-

It starts with a question about creating static members of 'classes' in
javascript:-

<URL: http://groups.google.com/group/comp....a2a95df1e355ca >

Both Douglass Crockford and I answered that question, and we both gave
the 'accepted wisdom' answer of the time; that static members were
created as public properties of constructor for the 'class'. You will
notice that Douglass Crockford does not mention any possibility for
private static members, nor does he hint at any possibilities in that
direction.

Laurent Bugnion responded to one of my posts saying that as far as
he knew there was no method of creating private static 'class' members
(Laurent Bugnion being one of the individuals who would have been
expected to know of a method if a method had been known at the time).
And that got me thinking, because I knew about Douglass Crockford's
method for creating private instance members and just felt that there
must be some way of doing a similar thing at the constructor/'class'
level to create private static members (or at least emulate them in
a way that was sufficient for all practical purposes). Fortunately
(from my point of view) at the time I was getting interested in the
functional programming aspects of javascript and had been exposed
to, and surprised by, the inline execution of functions expression
in examples such as:-

<URL: http://groups.google.com/group/comp....da01126dd6ea8c >

So with that concept sitting in the back of my mind, after a few hours
struggling to find some devious means to apply Douglass Crockford's
method for creating private instance members at the 'class' level the
penny eventually dropped and wrapped the 'class' constructor in the
inline execution of a function expression and had a private scope at the
class level, and so somewhere to put 'private static' members. So I
posted that (7.48 pm GMT April 23rd 2003).

Using the inline execution of a function expression to create a 'private
scope' is the essence of the module pattern, and it rapidly became
apparent to me that it had more immediately practical applications than
emulating private static members of 'classes' (especially given that
javascript authors had been, at the time, getting by quite happily
without private static members for the previous 8 years). The direction
I immediately took was to create self contained stand-alone modules
wrapped in the inline execution of function expressions, and these are
the 'module pattern', the first examples of which were published in the
(historically extremely significant) "closures, what are they good for?"
thread (in my May 8th post (that is May 9th local time (BST))):-

<URL: http://groups.google.com/group/comp....3cd655ad56fe91 >

The following two years witnessed the publishing of a steadily
increasing number of 'module pattern' implementations, along with the
examination and development of the ideas behind it. For example, the
'singleton' implementation that is the subject of the YUI blog page on
the 'module pattern' first appeared in August 2003:-

<URL: http://groups.google.com/group/comp....a52610080c9de3 >

The bulk of the work in the field was done by Yann-Erwan Perio (Yep),
Lasse Reichstein Nielsen, Michael Winter and myself. Indeed I have no
recollection of Douglass Crockford ever even commenting on the idea,
though he obviously was paying attention.

He's never once mentioned Richard Cornford.

Mentioned me to who? If nobody asked the question then they would never
have heard the answer.

(I will answer the rest of your post tomorrow, or later in the week.)

Richard.

[Dr J R Stockton]

In comp.lang.javascript message <72041073-fe46-4478-97fb-e06e9081fbf3@i2
9g2000prf.googlegroups.com>, Sun, 25 Nov 2007 14:40:45,
"dh**********@gmail.com" <dh**********@gmail.composted:

>
Other things, like the lack of a DateFormatter, will continue to be
frustrating in those cases. Methods similar to those JR Stockton
proposed here are going into Date, though.

But will they be sufficient, well-designed, and error-free? Will, by
using them, users be able to comply with all relevant international
standards, ISO and other, without additional effort?

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Dr J R Stockton]

In comp.lang.javascript message <55582ec7-ee15-4cdb-a028-3340b0c8c153@s8
g2000prg.googlegroups.com>, Sun, 25 Nov 2007 17:23:18,
"dh**********@gmail.com" <dh**********@gmail.composted:

>On Nov 25, 3:31 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>What are you talking about? ES3 does not specify algorithms that depend or
rely upon ToString() return values. It defines the implementation for
ToString() and for the toString() method of built-in objects, and rightly so.

Date.prototype.toString is defined to return something parseable by
parse()

To me, it looks more the other way round; Date.parse is defined as
accepting anything that Date.toString() can generate.

But I see nothing to prohibit Date.toString() returning, for today,
2007-W48-1 or 2007-330. The former is more useful than 2007-11-26,
since it clearly indicates not only the time-of-year but also the day-
of-week, both of which have far more practical effect than day-of-month.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[dhtmlkitchen]

On Nov 26, 11:42 am, "Richard Cornford" <[e-mail]>
wrote:

<[e-mail]:

On Oct 27, 2:28 pm, Richard Cornford wrote:

<[e-mail]:
On Oct 22, 4:01 pm, Richard Cornford wrote:
[e-mail] wrote:
On Oct 22, 12:33 am, Richard Cornford wrote:
[e-mail] wrote:
<snip>

<snip>

<snips>

>
You mean in cases where someone needs a date formatter but does not know how to write or find
one for themselves?

Writing a DateFormatter correctly, considering L10N, is no simple
task.

>

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.

"might" be expected. That's where I see the problem. it's
like you can't be certain what's coming out of it.

You can be certain as soon as there is a specification stating what will be coming out of it.

Docs can be boring and time consuming (for many); A sensible API with
obvious method signatures, on the other hand, does not prevent someone
from delving into the details of API docs.

>Why is adding the parse method to String correct?

It is neither correct nor not correct. Rather it seems to
be expedient and harmless otherwise.

It would be incorrect on Date, right?

And is that being proposed?

Date.prototype.parseJSON : Object - seems to violate
principle of least astonishment.

So why is that relevant to whether string objects should have such a method?

If String.prototype, why not Date.prototype? or why String (orig)?

<snip>

<snip about precedence>

>

I would think use case, side effects, and how the API is
used would be more relevant.

toSource isn't in wide use because it's proprietary, non-standard.

Yes, but it still demonstrated that having the method is not of itself harmful or problematic.

It's a useful feature,

No, it is not that.

<snip>

>

>So why add another?

Because the addition you are talking about makes no practical
difference. It does not introduce anything new (object
serialisation has been a reality for a considerable time
already) and so its only contribution to the ability of
'programmers' to do stupid things is providing another
Identifier that can be put after a dot and before an
arguments list without the result actually erroring on
the spot.

Cross browser?

Your point being?

toSource is not really practical for use in the mainstream; noone
realistically expects it to work cross browser, don't you agree?

>And besides,toJSONStringwould 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.

Then don't call it. Your tool tip manages to get by
without you calling - toSource - on it.

Well, clients might call it,

Clients? What are you worrying about here? That code that works OK if used as instructed might
not do anything sensible if exposed to someone who randomly types method calls on its objects
without understanding what they are doing? Well yes, garbage in - garbage out. We might worry
about the those same individuals being in possession of pens, pencils and other pointed objects
in case they put their own eyes out.

toJSONString was proposed to be part of any object's public interface.

A menu, datagrid, sortable list, et c [insert-your-fav-widget]
implementations might really want serialization. Even if their API
didn't consider it!

The API designer might not be considering serialization, or might have
partially considered it (worse) but the toJSONString hook has already
been added; it's a part of the API. This part of the API might,
coincidentally, work for the user.

They would not be correct in doing so unless they understood what the outcome of their actions
was going to be, at which point whatever the outcome was it would be both expected and desirable
in context.

When Tooltip 2.0 comes out, then toJSONString -- a
contract that Tooltip was forced into -- has different
results (which the Tooltip author may have neglected
to consider).

You have been saying that it makes no sense to serialize Tooltip at all, so when Tooltip 2.0
comes out it still makes no sense to serialize it.

Serialization might make sense for one user of Tooltip.

But the Tooltip API developer doesn't want to concern himself with
serialization; it makes Tooltip less cohesive. When he changes his
code for 2.0, the code still works great.

But someone else was relying on the serialization of toJSONString, so
their code breaks.

>

Developers on my last gig were seriously confused by the
module pattern and would think that it was a namespace or
part of the namespace.

So they were trying to use closures without first understanding closures and their mechanism?
Aggravated by someone throwing one of those stupid 'namespace' constructs into the mix?

That pretty much sums it up. I'm not going to debate the namespace
issue now. Save that one for another topic.

I was there till 8 or later many nights. 10 hour days
fixing this stuff, so yeah, pretty annoying.

Fixing the products of individuals who where never qualified to do the jobs they were attempting
is usually annoying.

Especially when refactoring is almost banned.

<snip>

>
What is this you are posting? Is it real code or something you made off the top of your head for
some reason? Are we really dealing with developers so inept as to be thinking that 'foo' and
'bar' were sensible names for namespaces?

Off the top of my head but based on real code. I don't have it on
file, unfortunately. I've edited the code snip below.

The F/E programmers weren't great; the project recs were not simple,
we were using YUI, and other developers were influenced by practices
they had applied individually (not collaboratively).

}
YAHOO.foo.bar.
function baz(x){ return x; }; // Function with hasGlobal for
[[Scope]]
// 1100 lines or so snipped..
return {
hasGlobal : false,
// baz method which points to baz (3)
baz : function(x) { return /*YAHOO.foo.bar.*./ baz(x): }

^^^^^^^^^^^^^^^^^

(code snippet edited).
<snip>