Having to 'spin up' on a script is pretty common for JS engines, V8 does the same thing as the low optimizer collects information.

It seems to me that all rotations should be anti clockwise, with an angle of 0 being normal. I could live with 0 being top-to-right though, that's more trigonometrically correct.

Problem with Jurassic:

I run this bit of code:

Code: (javascript) [Select]

function game()
{
    var prop = 8;

    var a = {
        get prop() { return prop; }
    };

    Abort(a.prop);
}

In Sphere 1.5/1.6 with Spidermonkey 1.5 it will print out 8.
In Sphere SFML with Jurassic it will print out "function prop() { return prop; }".

Obviously there is a scoping issue in one or the other. I'm betting that Spidermonkey is itself nowhere near the ECMA standard, but it could also be that the Jurassic parser missed a corner case. And since Jurassic uses a recursive decent parser I don't know where the grammar is to change besides to hand-roll the correct procedure for resolving the right scope. It could be a complex issue!

But I'm not certain it being a scoping issue. Because this works in both:

Code: (javascript) [Select]

function game()
{
    var other = 8;

    var a = {
        get prop() { return other; }
    };

    Abort(a.prop);
}

So long as it doesn't used a variable named after the getter/setter call it will work just fine.

I'm not completely sure here, but my instinct is telling me the function printout is the correct result, since if you don't consider the name of the containing function before anything else, a case like this would break recursion.  I don't know about you, but for me, from a langauge-design point of view, being able to completely break a working inner block by a modification to its containing block (not counting syntax errors here, obviously) strikes me as bad juju.

Well, I put it into the discussion at the Jurassic page, the problem with Jurassic is that it's no longer being developed.

Well I think that since 'prop' is defined as a variable outside of the scope of the object a, it becomes bound to the function. But then again it is impossible to get to the getter any other way since "return this.prop" will put it into a loop that basically ends when the stack runs out.

Hm, well here's a question.  How does Jurassic handle return prop; when there is no such variable in the outer function (i.e. the only thing named 'prop' is the property itself)?  What about SpiderMonkey?  If you get the function listing as output from both in that case, I'd say that's the correct result, since otherwise you have inconsistent scoping.

I always like to do little experiments like this whenever I run into a snag, gives me more insight into how things work under the hood.

Vanilla Sphere: "prop is not defined"
SFML Sphere: "function prop() { return prop; }"

Which is strange. That means unlike JS fashion it is not easily possible or possible at all to get the getter function in Sphere 1.5/1.6. 

Haha, see what I mean?   Now you know more than you would have if you just assumed it was a scoping error!  Turns out it is, but now you know the error is most likely on SpiderMonkey's part, not Jurassic's.  Unfortunately I can't offer any more input here since I don't know what the standard says about it...

ES5 11.1.5 is fairly clear that nothing is added to the lexical environment for getters/setters in object literals, so SpiderMonkey is 100% correct in both cases.
Additionally, according to ES5, a variable already in scope is not overwritten when a function declaration is made with the same name. Since these aren't really function declarations I don't think this applies, but even if it did SpiderMonkey would still be right.

What do the consoles for Chrome and Firefox output?

Code: (javascript) [Select]

function testPropertyScoping() {
    var prop = 8, o = {get prop() { return prop; }};
    return o.prop;
}
testPropertyScoping(); // 8 in both Chrome 30 (Canary) and Firefox 22 (Stable).

function testPropertyScoping2() {
    var o = {get prop() { return prop; }};
    return o.prop;
}
testPropertyScoping2(); // Both throw ReferenceError: prop is not defined.

Good news; it's been fixed. The maintainer is still active in the discussion board over at codeplex.

a variable already in scope is not overwritten when a function declaration is made with the same name.

...wow, that's... not what I'd expect at all.  That means if you have a named, recursive function and move it into a scope where a local variable by the same name exists, the entire function would break.  From a language-design point of view, that's just asking for trouble.

...wow, that's... not what I'd expect at all.  That means if you have a named, recursive function and move it into a scope where a local variable by the same name exists, the entire function would break.  From a language-design point of view, that's just asking for trouble.

JavaScript as a language is just asking for trouble.

It's possible I interpreted the spec wrong however. In both Chrome and Firefox,

Code: (javascript) [Select]

function outer() {
    var inner = 5, fn = function inner() { return inner; };
    return fn;
}
outer()(); // function inner() { return inner; }

seems to confirm that. And yes, I know that's technically a named function expression, not a function declaration.

...wow, that's... not what I'd expect at all.  That means if you have a named, recursive function and move it into a scope where a local variable by the same name exists, the entire function would break.  From a language-design point of view, that's just asking for trouble.

JavaScript as a language is just asking for trouble.

Haha, so true, and yet I've had more fun programming in JS (and thus, more productive) than any other language I've ever used.  Go figure!

The bleeding-edge version of Jurassic is like 33% slower. Arrgh! :/