Posted: May 11, 2006 1:51 PM
> Thanks for the links.
> had an object model slapped onto it for page
> That's it. I had a hard time putting my finger on it
> in my mind to DHTML and AJAX is "onmouseover" et. al.
> That is, while the various event handlers are not part of
> f the language per se, because there is no standard
> library they are generally presented as builtins. And of
> course, if the builtins are specialized for page
> presentation ... (yes, I know I'm wrong, but that's where
> my mistake came from).
The only built-ins browser JS specifically for browsers are the
window object, some extra methods on the
Global object, a few extension methods to the
String object, and a few other miscellaneous bits. But as far as JS itself goes, they could be part of a library that gets automatically included and aren't really tied to the language itself.
> Prototype-based OO:
I put that link in there because some think that prototype-based OO is inferior or a subset of class-based OO, when all it does is get rid of the dichotomy between objects and classes. The two approaches are isomorphic however.
> /* Support for multi-threading isn't as important as you
> might think,
> Well, I do like C++ and Perl. Standard C++ doesn't
> offer multi-threading, and while Perl does, it's
> relatively new. Either way, it's not so important to
> have multi-threading as it is to make sure the
> standard doesn't prevent multi-threading.
> /* [Me] Since the compiler is part of the runtime
> [response] JS is usually interpreted.
> Exactly. I get this way of looking at things from Perl,
> which makes a big deal about whether the compile phase or
> the interpreter is the culprit for limitation X or Y. If
> I'm working in C++, and I want builtin multimethods, I can
> simply standardize on a [a href =
> that offers them[/a].
When you're doing that, you have the advantage that your source doesn't have wide distribution. But, say if you're developing intranet code and the company's standardised on a browser that supports E4X (EMCAScript for XML, Firefox is an example), you'd be able to use extensions that includes.
And I wish more languages supported multimethods too. I'm sick of having to hack them using the Visitor pattern.
> However, that kind of standardization is not possible with
> interpreter, a.k.a., the compiler is part of the runtime
Yup, but you can say that about almost any interpreted language, save ones with powerful macro systems like Lisp.
> Nice or Jython do to Java, because even if I have a tool
> my customers don't (unless I write a browser plug-in).
I'm not entirely sure I'm getting your point here, especially if you bring libraries into it. Say I write something in Jython or Java, build it against Java 5 and give it to somebody still using the Java 1.1 Runtime: it's not guaranteed to work right for them because of library dependencies and other things.