Type Parameters are Completely Unnecessary

Darryl psygnisfive at yahoo.com
Tue Mar 4 23:20:38 PST 2008

<< Notice now that you can't check anything about the
type passed to  
TypedSet. For example, you can't check (at runtime, or
using the  
optional strict mode, doesn't matter) that Number is a
subtype of  
some other type. Also, the implementation can't
optimize, e.g.  
Vector.<double> into packed double[] storage. >>

Then I would argue that the implementation is flawed.
Implementation should not factor into language design.
If it did, we'd end up with having JS be just C with
the dangerous stuff cut out, and then compiled on the
fly, because surely that would be simpler than
designing a whole new language, but that's an absurd
prospect. Make the language do what you want it to do
elegantly and simply, and then figure out how to make
it work. This "solution" seems more like you said,
"Oh, crap, how can we put this into syntax given how
we're implementing JS?" and that to me is completely
backwards in terms of language design.

<< That's not type-checking in the optional types
sense. It's tedious  
and error-prone, and hard enough that people tend not
to write such  
code, instead using duck typing in a more "if it
doesn't quack like a  
duck, step on it!" way.

Type parameters follow naturally from wanting types to
be first class  
runtime terms, not just values that have to be checked
manually. >>

I'm not saying it's an ideal way of doing things,
maybe you could do something like 

Class TypedSet(contentType){

	function add(obj:contentType){

Oh sure, JS2 as-is might not be able to cope with
this, but there's no reason at all why you couldn't
make it cope. And that's the point. This is a trivial
difference, no change in syntax just in how you can
use things. It's purely a semantic difference, but
it's immensely more elegant and understandable.

<< I guess my plea to put aside syntax and aesthetics
didn't work.  
You're being blinded to the meaning, which is where
the motivation  

Would you prefer Set<Number> a la C++, Java, and C#?

Syntax and aesthetics are incredibly important, tho,
in conveying meaning. If meaning is all you care about
then why not use some incomprehensible way of
representing type restrictions? Because languages need
to be usable and elegant to be _good languages_, not
merely capable of doing something. I don't want
Set<Number> either (tho seriously, why would you add a
dot that conveys absolutely nothing and complicates
the notion of what dots do?), I would prefer something
more consistent with the notion of what JavaScript is.

<< Types are not all classes. There are structural
types (even today,  
latent in ES3: functions are structural, not nominal).

Maybe they should all be classes. Plus, I don't see
why it should matter what ES3 does. This is ES4, not
ES3. I understand the desire to be somewhat backwards
compatible, but letting that hamper the language is
foolish. Sometimes you just have to say, "This is
completely new, but it's better because of that."

<< Have you read the overview doc at
http://ecmascript.org/ yet? >>

Oh I've tried, but it's not the most user friendly
website out there.

Listen, I understand that this isn't going to change
your mind about the issue, because you're well on your
way to making this thing finished. You've said many
times before that the spec has been finalized. But
it's worth pointing out that the language is still
designed in less than ideal ways. It's only by virtue
of the fact that JavaScript is the only language
natively executable by web browsers that makes this
sort of thing even remotely possible. If multiple
languages were available I think you'd end up worrying
that JavaScript might go out of fashion like Fortran
regardless of what it can do.


Be seeing you...

Never miss a thing.  Make Yahoo your home page. 

More information about the Es4-discuss mailing list