When I ran it, I got an error:
c:\kjk\src\tiscript>obj-rel-win\tiscript.exe nbody.js
Error: Object undefined has no property - offsetMomentum
at nbody.js(nbody.js:22)
I managed to create a simpler repro case:
function f(x) {
this.x = x;
}
f.prototype.off = function(y) {
this.y = y;
return this;
}
Running this gives me the same error:
c:\kjk\src\tiscript>obj-rel-win\tiscript.exe simple.js
Error: Object undefined has no property - off
at simple.js
Is it intended departure from JavaScript or a bug? If intended, any
chance that it can be made JavaScript-compatible in the future?
I'm asking because I think the more language is compatible with
JavaScript, the better.
http://www.terrainformatica.com/wiki/tiscript:objects_and_prototypes
says that "This schema of instance-of relationship is simpler and thus
different from the one used in JavaScript" which implies that current
implementation is different than JavaScript when it comes to prototype
field, but it doesn't elaborate how is it different or why is it
different (is it implementation issue? a better way to do things?
historical accident?).
On a separate issue, when a script is ran from command line and an
error is thrown, currently we're left in the shell but we should just
exit - it seems to be unspoken standard of scripting languages. This
change seems to be simple enough that I can give implementing it a
try, but I don't want to make behavioral changes that others might
disagree with so please let me know if you think such a change would
be ok.
Thanks,
-- kjk
>
> In order to evaluate tiscript I picked up a random JavaScript
> benchmark from programming language shootout. It happened to be n-body
> simulation
> (http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbody&lang=javascript&id=0)
>
> When I ran it, I got an error:
>
> c:\kjk\src\tiscript>obj-rel-win\tiscript.exe nbody.js
> Error: Object undefined has no property - offsetMomentum
> at nbody.js(nbody.js:22)
>
> I managed to create a simpler repro case:
> function f(x) {
> this.x = x;
> }
>
> f.prototype.off = function(y) {
> this.y = y;
> return this;
> }
tiscript uses more traditional class declarations:
type F
{
function this(x) { this.x = x; } // ctor
function off(y) { this.y = y; } // method
}
var f = new F(); // call of F.this ctor
f.off(2); // call of off method
-------
Would be interesting to see results of your tests.
>
> Running this gives me the same error:
> c:\kjk\src\tiscript>obj-rel-win\tiscript.exe simple.js
> Error: Object undefined has no property - off
> at simple.js
>
> Is it intended departure from JavaScript or a bug? If intended, any
> chance that it can be made JavaScript-compatible in the future?
Intended. There are quite a few people who *really* understand how
prototypes work in JS.
It is possible to implement ECMAScript prototyping though but
I suspect that it will be incompatible with 'type's
>
> I'm asking because I think the more language is compatible with
> JavaScript, the better.
I thought about this too. But who needs yet another JS implementation?
There are 6 or so JS implementations already.
>
> http://www.terrainformatica.com/wiki/tiscript:objects_and_prototypes
> says that "This schema of instance-of relationship is simpler and thus
> different from the one used in JavaScript" which implies that current
> implementation is different than JavaScript when it comes to prototype
> field, but it doesn't elaborate how is it different or why is it
> different (is it implementation issue? a better way to do things?
> historical accident?).
I was asking on many conferences for an idea of why JS is using such
non-trivial system of prototypes. None was able (yet?) to explain me
why it was implemented that way. In short:
Having variable var s = "string";
In JS this true:
s.__proto__ === String.prototype;
And in TIScript following is true:
s.prototype === String;
So in TIS
obj.prototype is a reference to class object of some obj. That is it.
And how prototypes were made in JS you may find here:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Property_Inheritance_Revisited
>
> On a separate issue, when a script is ran from command line and an
> error is thrown, currently we're left in the shell but we should just
> exit - it seems to be unspoken standard of scripting languages. This
> change seems to be simple enough that I can give implementing it a
> try, but I don't want to make behavioral changes that others might
> disagree with so please let me know if you think such a change would
> be ok.
I think it is ok to change it.
Andrew.