The example was taken from Java, to illustrate the concept
that XXX.parse is usually expected to return an XXX.
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.
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?
BTW, global is accessible in ES4.
Like a date string? A Number? How about...
A Date ?
Any.
Ding, ding, ding!
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.
Should the String constructor be morphed into a parser?
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.
toSource is limited to Spidermonkey, AFAIK.
It is quite widespread in implementations that attempt to be
JavaScript(tm) compatible in addition to being ECMA 262 compatible. But
regardless of that, electing never to use a method that an object may
have is not significantly distinct from using an object that never had
the method to start with.
toJSONString will be an ES4 standard.
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.
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.
Then don't call it. Your tool tip manages to get by without you
calling - toSource - on it.
Like the Power Constructor, the Module pattern.
These are examples of "misuses" of "for-in loops, or closures"?
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.
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.
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).
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 Patterns >
- 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;};
- and all 'protection' is gone. There are two attitudes towards the
notion of 'protected' in javascript; the one that says that you can
achieve everything necessary with naming conventions and documentation,
and so avoid the runtime overheads of the alternatives, and the one that
says that programmers using the code cannot be trusted to obey the
naming conventions and documentation and so things that should be
'protected' must be properly protected, despite the overheads. Either
are valid positions to take, but you seem to be going for the latter,
where the programmer cannot be trusted to use the system as designed and
so must be prevented from abusing it. But then you leave the door wide
open for this abusive programmer to knock your 'protection' out at a
single stroke, when you have already decided that he/she is precisely
the sort of programmer who will do just that sort of thing (that is, you
have decided that documentation saying that the singleton constructor is
not to be used directly will be disregarded, but expect the same
individual not to subvert your 'protection').
Here we see the advantage of Douglass Crockford's realisation that
closures could be used to provide some real 'protection', and the
extension of that idea into the 'module pattern' (and related concepts).
Protection with closures becomes physical, and subverting it becomes so
involved that the individual trying to subvert it may as well just
re-write the 'protected' code the way they want it and forget about the
original.
A 'module pattern' singleton implementation of your singleton "Design
Pattern" could go:-
var Tooltip = (function(){
var instance;
return ({
getInstance:function(){
return (
(instance) ||
(instance = {
ACTUATOR_CLASSNAME : "tooltip",
show:function(){
//some code.
}
})
);
},
purgeInstance:function(){
// Clean up all listeners.
instance = null;
}
});
})();
- and require half the code (not needing the elaborate and pointless
'protection' methods of the Function constructor or a constructor of its
own), achieves superior protection because it becomes a simple
impossibility to call any singleton 'class' constructor directly because
there is no such constructor, and because the code is 100% ECMA 262 3rd
Ed. code the result is also compatible with IE and so does have
commercial viability.
Now that code will likely be confusing to novices, and probably
surprising to people coming to javascript from other languages (and
particularly to those expecting javascript to be a cut-down Java).
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.lang.javascript/browse_frm/thread/4eda01126dd6ea8c >
(That post may include the first example of the inline execution of a
function expression ever. I would be interested in any examples
pre-dating that one, but those of you who remember Yann-Erwan Perio
(Yep) will recall that he was just the sort of playfuly inventive coder
that easuly could be the first to employ such a construct ever.)
My first reaction to seeing that was "you can't do that", shortly
followed by "****, you _can_ do that", and then "If you can do that then
.... " whole new horizons of possibilities open up which eventually
(mixing in the influence of Douglas Crockford's emulation of private
instance members) leads to the creation of the module pattern by May of
the following year.
So yes, for module pattern code not to be surprising and confusing you
need to understand function expressions, lexical scopeing and closures,
and maybe have been shown how it works once or twice, but that isn't
really any more than saying that you need to understand javascript in
order to understand javascript code. There is nothing inherently strange
or confusing in the pattern itself.
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.
So people who struggle to do their jobs may not do those jobs
particularly well? That is hardly a revelation.
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?
Nothing went wrong. The - propertyIsEnumerable - method did exactly what
it was specified as to do. If you see that as wrong then its is your
expectations that need adjusting.
propertyIsEnumerable does not check the prototype chain,
but for-in does.
Absolutely.
That is a bug.
No, it is the way things have been designed to be. Maybe that was not
the best of design decisions, but still everything is behaving in
accordance with the design.
Yes, well, *mostly* the bug itelf is incosistent.
No, that big is consistent. If you perceive it as inconsistent that just
means you are yet to properly identify the cause and effect
relationships that apply to it. Computers are inherently consistent, and
so bugs are also inherently consistent.
({prototype:1}).propertyIsEnumerable('prototype'); // well,
what does JScript think?
JScript objects have no - prootype - property on their prototype chains
to inherit so they cannot erroneously inherit a - DontEnum - attribute
through their prototype chain.
(Function()).propertyIsEnumerable('prototype'); // well, what does
JScript think?
Dynamically created function objects each have a - prototype - property
themselves, and it should not be marked with the - DontEnum - attribute
so this is an ECMAScript bug, though not the same bug as the prototype
chain inherited -DontEnum - bug because there should (by default) be no
objects on a function object's prototype chain with a - prototype -
property (as their prototype chains consist only of Function.prototype
and Obejct.prototype, neither of which have a - prototype - property by
specification).
All JScript bugs aside, Object is a generic type. HashMap, or
Map<String,Object>, is specific.
Not in ECMAScript 3, as there is only one object type there.
It says: I'm a data structure.
Or the programmer says it is a data structure.
Well, instanceof was there first.
"First" in the sense of them both being introduced in ECMA 262 3rd Ed.?
In ES4, it will work across frames.
So no back-compatibility there either.
It will be used. A lot, I think.
It will be used where using it is useful, not in an arbitrary manner
with any object that may come along.
Enumeration has nothing to do with Object as a type.
Explain.
The feature causes problems that have been the topic
of discussion for years.
The vast majority of those problems being the direct result of
individuals having unrealistic expectations of how enumeration of object
properties should work and so having their expectations disappointed by
reality. Start out with realistic expectations and no issues follow
(mostly because 90% of the apparent applications of enumeration are then
seen as inappropriate and better alternatives employed in their place).
I've had my share of problems with this. Mostly related
to the JScript bug.
Maybe you have, but you have expectations that are not technically
informed or realistic, so you are likely to encounter issues. That is
just a symptom of your being a relative novice at javascript. As you
learn the language these problems will go away.
Did anyone say it was? It is just something that is going to be used,
probably used increasingly (possibly replacing XML/SOAP in all browser
client-server data exchanges) and something that will benefit form
handling in native code rather than (inevitably slower) javascript code.
for those who think it is, a native JSON object will provide
the same functionality, and will do nothing other than
provide such functionality.
Besides being misnamed propertyIsEnumerable is broken.
You are yet to present any evidence for this 'brokeness'.
Because it means that by default, Widget MUST tackle this
responsibility. Widget is Serializable, even if I don't want it
to be,
Don't want it to be serializable or don't' want it to be serialized? In
both cases that is already no more than a whim on the part of the
programmer because the existence of - toSource - means it already is
serialzable.
I, as a programmer, have had that right taken away. That sucks.
You have not lost the right to 'want' and you never had a reason to
'expect'.
A Tooltip.show() method seems pretty rational to me. What does that
have to do with data structures?
What does it have to do with JSON, given that JSON sub-set of object
literal notation precludes properties with function values?
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.
That seems reasonable under the circumstances.
Not required, but they do, in many browsers.
Some do and some don't. You don't create cross-browser code by assuming
thing will exist when they actually may or may not exist.
In those cases, it will
be required to deal with serialization.
Well, they already do where - toSource - exists along side input
elements inheriting form Object.prototype. People seem to get by with
things the way they are.
And Callable is an Object, and a subc'd String is a String.
What are you talking about?
How is adding JSON methods to all objects justified over
adding a separate Class/Object to handle serialization?
Visibility would be one justification. As a method of object instances
the serialization method is no more problematic or significant than
toSource, but stuff a new object 'class' into the global namespace and
there will be knock-on effects for compatibility.
Not harmless when my Tooltip has to be responsible for serializing
itself.
<snip>
What do you mean by "responsible for serializing itself"? If you don't
want a sterilized tool tip don't call the method and you will not have
one.
Richard.
