js api: version - would a build date be more useful?

[aubergine]

Currently the "version" global is something like: TRUNK

Would it be worth having "version" contain the date of the build as a number (eg. Date.getTime() style) instead?

This way, JS devs can adapt their script to API changes using something like:

Code: Select all

var foo = (version >= dateOnWhichSomethingChanged)
  ? function() { ... }
  : function() { ... };

or within a function:

Code: Select all

function foo() {
  if (version >= dateOnWhichSomethingChanged) {
    // do it the new way
  } else {
    // do it the old way
  }
}

In JavaScript it's easy to create a date:

Code: Select all

var dateOnWhichSomethingChanged = (new Date(year, month, day)).getTime();

Alternatively, version could be left as is (eg. TRUNK, MASTER, etc) and add a new buildDate global which contains the date in ms since 1st Jan 1970.

[NoQ]

Well, some v3.1beta3 will have later build date than current master, but it will still have old buildDroid function.

We need not only the date, but also the branch.

[aubergine]

ok, so version stays as is (eg. TRUNK, MASTER, 3.1, etc), and add new buildDate global

[Emdek]

Real solution is to have API levels instead.
Also now it is work in progress so things will break, can eat your cat etc.
And this reminds me purpose of jQuery and others, to hide differences between different browsers (or more precisely, different JS engines).

[aubergine]

So, I'm developing something called vQuery - which is like jQuery but for warzone JS scripts.

However, it can't really "sniff" the API like jQuery can sniff browser features/versions. So there needs to be some way for scripts to accurately identify what version of the API they are speaking to (or what version + build date is in use) and then I can smooth over the bumps with vQuery.

[Emdek]

Yes, global property containing API version (could be date string for now, I guess) is the real answer.
But AFAIK checking for functions existence etc. should work like in "normal" (like in browser) JS anyway.

[aubergine]

It's not just the function's existence, it's the parameters it takes. For example: viewtopic.php?f=35&t=8912

With the current API there's no easy way that change can be detected from the JS end of things. The number of parameters (which can be checked with buildDroid.length) is the same, and version isn't descriptive enough (either "TRUNK" or "MASTER") to differentiate between API versions.

In browsers they can quickly create hidden divs and stuff to check for features, etc. In Warzone, to check the above function, a factory would need placing, then instructed to build droid with "null" as the droid type param, then catch the error = must be on old version. The delete the factory. While that is do-able with the current API, it's very crufty.

[aubergine]

One other thing to note is that in browsers there's usually some way to work around missing functionality because even in old browsers their API (eg. HTML DOM, etc) is huge giving lots of alternate ways to do things. In WZ we have a limited set of very specific functions, etc., that can't be abused in to doing different things.

[Emdek]

Maybe we could use solution like this (would break existing ones or would need to live in parallel):
http://www.javascriptkit.com/javatutors ... tion.shtml

Or add global object returning function information (parameter list, function version maybe too etc.), like built in man (also AFAIK Python has something like that).