Re: Current JSON Proposal in ES4

On Oct 27, 2:28 pm, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
wrote:
<dhtmlkitc...@xxxxxxxxx> wrote:
On Oct 22, 4:01 pm, Richard Cornford wrote:
dhtmlkitc...@xxxxxxxxx wrote:
On Oct 22, 12:33 am, Richard Cornford wrote:
dhtmlkitc...@xxxxxxxxx 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.

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

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.

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

Number.parseInt

Wouldn't the implication of your previous statement be that if -
parseInt - was a method of the number constructor then its output would
be a Number object not a number primitive?

Agreed.

This also be justifiable placed on Integer.

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 ?

Any.

We clearly have different opinions on API design. I argue that
XXX.parse should return an XXX because it seems obvious.

<snip>

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

Wasn't it - String.prototype.parseJSON - that you were
objecting to?
Yes.

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.

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? Date.prototype.parseJSON :
Object - seems to violate principle of least astonishment.




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.

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.

It's a useful feature, but the implication of changing Object's
interface to say it's serializable -- that's what I take issue w/.

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

That doesn't matter in context. The method exists, has existed for some
considerable time, and it has (and is having) no negative impact on the
use of objects in JavaScript(tm) or ECMAScript. Ignoring its existence
is sufficient, and any second similar serialising method can just as
effectively be ignored when not wanted with the same outcome.

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.

As it stands javascript only has one object type, and augments that
object to create what then become its various built-in types. Then
programmers who want multiple 'types' of object set about augmenting the
native ECMAScript object into the various 'types' they want. In the end
there is still not actual distinction between the 'type' of these
objects beyond what has been done to them and how they will be used. And
that distinction comes from the programmer not the language.

If the programmer declares that 'these objects are data structures' and
'these objects are not' then that is his/her design decisions, but the
objects themselves are still all just the native ECMAScript object in
reality. Thus, even if all the objects have serialisation method (and in
JavaScript(tm) they already do) then the distinction between a 'data
structure' and 'not a data structure' may be no more than calling the
serialisation methods of the first and never calling it on the latter.

This is the reality of tiring to do OO programming in a language as
loosely typed as javascript. There is no 'type safety' and the
programmer is the one responsible for staying on top of that and
understanding how the notions of 'type' from their design are to be
used/handled in the resulting program.

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.

<snip>




toJSONStringwill 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?

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?

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, and would be perfectly correct in doing
so. 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). Maybe the client sees the
difference right away, or maybe the cleint's app seems to be working
for a while and then they realize that the serialization is different,
and includes an x property but the _id property is different.

toSource doesn't describe the object's public interface except in a
minority of browsers.

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 are examples of "misuses" of "for-in loops, or closures"?

Closures. I've got some explanation below of why it's confusing.

These things can and are often used to make really
strange and confusing code.

"Confusing code" can often be a matter of experience and knowledge. As a
relative novice you will tend to be confused by many of the more
advanced constructs used in javascript, and perceive some of those
constructs as strange. That is inevitably true for anyone coming anew to
any programming language.

It is also possible for code that is inherently strange and confusing
(to any audience) to be written in any programming language.


JavaScript seems to make confusing, strange code almost necessary.
It's more condusive to weird constructs (like my weird singleton you
mention below). It makes it awkward to do things that should be easy
and straightforward -- like private.

What is needed with of your response to my request for examples of
"misuses of for-in loop, or closures" is some evidence for "the Power
Constructor" and "the Module pattern" being such "misuses". Or even of
their being inherently "strange and confusing". Otherwise we are left
with your unsubstantiated assertions, and may be included to attribute
them as the result of ignorance on your part rather than being anything
of significance.

OK.

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. I was there till 8 or later many nights. 10 hour days
fixing this stuff, so yeah, pretty annoying. All this in an anti-XP
environment, developing a heavy, feature-rich, internal app, with
waterfall process.

YAHOO.namespace("foo.bar");

// WRONG: namespace converted to object.
YAHOO.foo.bar = (function(){

if(YAHOO.foo.bar.hasGlobal) {

}
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): }// Function 3
with hasGlobal for [[Scope]]
}
};

Now if there had been better teamwork and communication (and a smarter
mgr), they could have realized that the module pattern was causing
problems the way they were trying to use it. That started to happen
after I got there (more communication, pairing up, daily standups, et
c).

I think my boss told me to "change as little as possible" and "don't
break anything." Very hard to work with this code and boss, which was
very non-modular.

It took quite a long time to convince these guys to break stuff up
into multiple files -- about 5 months. We ended up with 25-30 files/
page. Convincing them not to use the memory-intensive module pattern
was more difficult, though they did finally see the mistake in the way
they were using it previously. They had just grown accustomed to it.

Doug Crockford seems to be taking credit for this pattern. He's never
once mentioned Richard Cornford.

Take "the module pattern" (as I am largely responsible for its
existence); about 6 months into to the development of the module pattern
the question of singleton pattern implementations came up, and it
rapidly became obvious that the module pattern lent itself extremely
will to that particular application. So much so that most introductions
to the module pattern have employed a singleton pattern as their primary
demonstration of the application of the module pattern (including the
well-known YUI article, where the name got attached to the technique).

The guys at Yahoo use this pattern and got really confused by it, I've
gone into detail w/this on the ES4 list, and above. Anyway, this is a
little OT.

On your web site you have a section headed "Design Patterns" which seems
to contain a single article that is a singleton pattern implantation:-

<URL:http://www.dhtmlkitchen.com/?tq=Design%20Patterns>

I like patterns, and the mindset taht goest into them (encapsulate the
parts that vary). I've used Factory, pub/sub, Command, and even State.
Haven't wrote them all out for JS, though.

- which I find strange, and many novices would certainly find confusing.
One of the main things about your code that I find strange is its
ham-fisted attempt to achieve a notion of 'private' for an exposed
'class' constructor. Having a constructor for an object that you only
intend to ever have one instance of is itself a strange design decision
in javascript, as an object literal is an ideal structure for defining
an object that will only ever be a single unique object instance. But
the really strange thing in your code is that it employs the
JavaScritp(tm) extension - Array.prototype.indexOf - method in the code
that is supposed to very that the 'class' constructor is not directly
used by external code, and so will not work at all with any JScript
versions. That is strange because any 'Design Pattern' that cannot be
used with IE browsers has virtually no commercial applications at all
and so is virtually worthless.

Another strange aspect of your implementation of "private" for the
'class' constructor is how trivial it is to subvert. All a programmer
has to do in order to use the singleton 'class' constructor directly is
first execute:-

Function.entryCheck = function(){return;};

Trivial to subvert, true, I actually sometimes forget in MY OWN CODE,
and reinstantiate when I really wanted JCO (just create one)_. that's
why I like the throw Error() over having a problem when you've got two
objects and the program expects no more than 1.

I'm really not satisfied with my "singleton" approach. A runtime error
is bad, and the other points you mention (confusing to others), the
constructor is accessible (not private), but has a doc comment that
says "private" (contradictory). The access modifiers in ES4 are really
what I want.

One more thing I should mention is that Thomas mentioned that there is
no Map in ES4. This is a false statement. Hopefully others won't be
confused by it. Just wanted to clarify. ES4 has Map<T,T>. The <T,T> is
parameterized, so can be var m:Map<String, Widget> = new Map(...)

Finally, I'm really glad to see that the TG1 group has decided that
Object.prototype.toJSONString is out, and have removed it from the ES4
spec.

Garrett
.

Relevant Pages

  • Re: Design Patterns and Functional programming
    ... Impurity is not required, as purely functional languages do exist, but it ... not the asymptotic complexity. ... this form of static checking requires the pattern matcher to be ... Then compiler leaves it up to the programmer. ...
    (comp.object)
  • Re: HOW
    ... Very strange. ... You just don't see that pattern with dunes ... crater to not be wiped out very quickly by sandstorms. ...
    (sci.astro.amateur)
  • Re: X-News Question ...
    ... If my slight rankling at being treated as though I am some kind of moron ... entered, or left, a pattern we have seen here before. ... an asshole with a chip on his shoulder /is/ a unique approach. ... then this must be a very strange group. ...
    (news.software.readers)
  • Re: Deleting a preloaded image from memory
    ... value to a variable in javascript. ... "The memory address"? ... where each bit pattern represents 1 ... The traditional representation of a bit pattern ...
    (comp.lang.javascript)
  • Re: Privileged constructor members
    ... follow the pattern described ... "Private Members in JavaScript" ... function XmlDeclaration(version, encoding, standalone) { ...
    (comp.lang.javascript)