EcmaScript - perl.perl6.internals

Message from discussion EcmaScript

Liorean

View profile

More options Nov 27 2004, 8:58 pm

Newsgroups: perl.perl6.internals

From: lior...@gmail.com (Liorean)

Date: Sun, 28 Nov 2004 02:58:40 +0100

Local: Sat, Nov 27 2004 8:58 pm

Subject: Re: EcmaScript

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby <ru...@intertwingly.net> wrote:
> Probably the best base to start with is Rhino, which is a standalone open source JavaScript compiler written in Java - originally done by the JavaScript team at NetScape. This code is quite good. And coincidentally is in the process of absorbing a set of patches to add continuation support.

Actually, I've spent the last couple of hours looking into three
implementations: Narcissus, Rhino and SpiderMonkey (and SEE a little,
too). I'd say Narcissus seems like a far better starting point for at
least two things: First of all, it's a JavaScript in JavaScript
implementation. Second, it's by far the easiest to get a grip of.
(Probably because of what language it's written in. C and Java
contains so much syntactic sugar...) The bad part is that Narcissus is
an interpreter and not a bytecode compiler, unlike the other two.

As for continuations, I've known about Cocoon for a while, and their
Rhino with proper tail recursion and first class continuations. It's
neat, and I'd certainly not go any other way. (Parrot should make this
easy, compared to JVM/CLR...)

> Overall, JavaScript would be a good match for Parrot. One place where it would significantly diverge at the moment is in the concept of a "class". Objects in JavaScript are little more than bundles of properites, some of which may be functions. And classes are essentially templates for such objects.

I don't really think it's that strange. Essentially, all objects
contain a reference to their prototype. When getting a member of an
object, the object will first check it's own members for the
corresponding identifier, then ask it's prototype, and so on until the
prototype chain is depleted. Setting is always done on the object
itself. It's really not so much inheritance as it is conditional
runtime delegation. Functions are of course first class and shouldn't
differ from any other member - there is no native method/property
distinction in JavaScript, even though host object may have such a
distinction. The difference between a function and a method is the
binding of the this keyword. Privacy is all handled by the closure
creation, so that should be a freebie with implementing constructors.

Note that the prototype delegation system could very well exist on an
object which inherits properties from a class, if the host allowed it.
The systems are orthogonal. But then I expect that to get ugly fast,
especdially with a Ruby-like class system... Hopefully LiveConnect can
be tweaked so that it can give the same automatic wrapping/unwrapping
of parrot native objects as it provides for Rhino and Java natives in
JVM.
--
David "liorean" Andersson
<uri:http://liorean.web-graphics.com/>

Reply to author Forward