Peter Michaux petermichaux at gmail.com
Wed Aug 13 20:02:27 PDT 2008

Reading the recent news about ES4 removing more of its old features
and morphing into Harmony, it seems that the related ideas of classes,
types and type checking are the surviving major new features.
Personally I've never quite understood why classes, types and
type-checking have been such a fundamental part of the proposal. I've
kept my fingers still about this for several reasons (mostly does my
opinion even matter?) but all of this type business seems more trouble
than it is worth to me (i.e. a daily JavaScript programmer.) Are these
type-related features what the community of ECMAScript 3 programmers
were really asking for emphatically years ago? Is the community really
asking for now with the surge of functional programming?


Looking in the new wiki page on types


I have a question about the use in browsers where multiple
windows/frames are involved. If a Date object, "d", is created in one
window and passed to a second window, will "Date.contains(d)" in that
second window be true or false? I would want it to be true, in this
case. The same question applies to non-built-in classes where the same
class name may be used in two windows with different class
definitions. I would want this to be false. Because of the second
example, it seems the result would necessarily be false. This makes
the test somewhat useless and goes back to duck typing where the code
using an object needs to inspect the object for the methods it will
call. The problem with duck typing is when different classes provide
identically named methods and the reason that in ES3, one way to test
if an object is an array is too look for an oddly named method like
Array.prototype.splice. I suppose what I'm asking is, given ECMAScript
is mostly in the browser and multiple windows/frames are part of that
environment, is this "contains" type check really good enough?


More information about the Es-discuss mailing list