Monday, September 29, 2008

Eval vs. Closure

Yesterday I made some experiments with respect to the relative speed of using closures vs. eval. For Joose these are the two options when creating accessor methods for attributes.
The results are quite interesting
  • On average executing a function that is not a closure and was created using eval is 30% faster than executing a closure
  • However, creating a function using eval takes about 200 times longer on worst case (FF3 on OSX)
This means using eval would create some significant gains for if you are executing an accessor method many times (you will need to be in the 10th of thousands for it to make a noticable difference). However, the increased cost for actually creating the function is currently prohibitive. With Joose we make sure that the compile time remains very small, because it will directly affect your page load time.

Thus, this will not go into Joose by default. We might still, however, create an option that lets you enable compiling accessors with eval for single attributes which are used very heavily.

Saturday, September 27, 2008

The == Operator in JavaScript

While working on the type constraint system, we got bitten by a pretty unexpected behavior of the == operator in JavaScript, that I wasn't aware of before. In our case is made a test case related to coercion pass, although no coercion was actually applied.
Here are some examples from the firebug console, that show the behavior:
>>> 1 == true
true
>>> 0 == false
true
So 1 equals true and 0 equals false. This can actually come in quite handy in many situations, where you are working with languages that have a similar understanding of truthness on the server side. Using the === obviously helps in this situation.

Friday, September 26, 2008

Type Constraints in Joose

Jeremy Wall of Google provided a great patch to Joose to actually hook up the long standing implementation of type constraints and coercions into the default attribute meta class.

So what does this actually mean:

First: You can build Types which are basically just things that express certain contraints for a value containers like an instance variable.
This is a type that will only allow boolean values:
Type('BooleanTest', {
where: function(value) {
if (typeof value == 'boolean') {
return true;
}
return false;
}
})
Now where this gets useful is if you add what is called coercions, which are just little functions that look at data and tranform them in a way that they match a type. Here is the type declaration with a coercion added, that turns 0 into false and other integers into true:
Type('BooleanTest', {
where: function(value) {
if (typeof value == 'boolean') {
return true;
}
return false;
},
coerce: [{
from: TYPE.Integer,
via: function (value) {
if ( value == 0 )
return false;
return true;
}
}]
}
);
Now we can build a class that constraints it's instance variables to be of type BooleanTest like this:
Class("BooleanTypeConstrained", {
has: {
attr1: {
is: 'rw',
isa: TYPE.BooleanTest,
coerce: true
}
}
})
We have to add the extra coerce: true, in order to enable the coercion because it does have a certain impact on runtime performance. What we can do now is this:
var constrained = new BooleanTypeConstrained();
constrained.setAttr1(1)
Without the coercion this would fail, because the field attr1 is contrained to be a boolean. However, because we added a coercion that transforms integers into booleana, this still works (and it actually sets the value of the instance variable to true).

I think that this can be a big thing for JavaScript programing, because when we do client side programming, dealing with user input is very important. With type coercions this becomes very declarative and easy. For example, you can have the user input a date in many different formats and then have coercions that transform these strings into instances of Date.

Thursday, September 25, 2008

Version 1.0 of Joose released



We are proud to announce the release of Joose 1.0. Download it now.

What's new in this version?

Joose is a self-hosting meta object system for JavaScript with support for classes, inheritance, mixins, traits, method modifiers and more.

Joose makes object-oriented programming with JavaScript easy, declarative and very productive. The Joose meta-object system is multi-paradigm. It supports class-based and prototype-based programming styles as well as class-based inheritance and role-based extention.

The Joose framework has been successfully used in multiple production systems for five months now and has been proven to be very stable. Joose is being tested using an automated unit-test suite that is being run in all major browsers (Firefox, IE, Safari, Opera and Chrome).

Tuesday, September 23, 2008

All new Version of blok

Over the last couple days I developed a major update for blok.
blok is a web based tool for colaborative editing of simple diagrams and user interface prototypes. Try it out here and please vote for blok at the app gallery.

Among the improvements are:
  • Ability to save and load documents with your Google account
  • New Welcome-Screen
  • Support for templates
  • Support for custom shapes (not yet enabled by default)
  • Better support for undoing operations that were performed on groups of shapes
  • More correct syncing between multiple editors
  • Faster speed in many situations
  • Better support for IE7, Safari and Chrome
If you find an error, please file a bug report.

Thursday, September 18, 2008

Truly private instance variables in JavaScript

Standard javascript objects do not support truly private instance properties (at least in a cross platform fashion). This means that even if you create get- and set-methods for your properties, an evil abuser of your interface can always get around this by simply peaking inside the object.

Leaving the arguments aside whether this is actually a problem or not, one can achieve the affect of private instance properties that only grant access through accessor methods by using closures which refer to a storage variable. A downside of this technique is the increased memory usage and increased object construction time, because these closures will have to be created upon every object construction so that the new object refer to their own private storage variable.

Here is some code that is demonstrating this technique:
MyClass = function () {
makePrivate(this, "test")
};

function makePrivate(object, name) {
var storage;

var field = name;

object[field] = function (newVal) {
if(arguments.length > 0) {
storage = newVal
}
return storage
}
}


var o1 = new MyClass();
var o2 = new MyClass();

o1.test(1)
o2.test(2)

alert(""+ o1.test() + o2.test())

o1.test(3);

alert(""+o1.test() + o2.test())


Another downside to this technique is that your instance vars are so private, even firebug cannot see them, so debugging will be much harder.

I'm currently pondering whether this technique would be a nice addition to Joose (hidden behind the regular class construction syntax). Putting this inside an attribute meta class would at least allow to enable a kind of debug mode that would make the vars visible during development.

While privacy might not be so relevant when you build all code for yourself, it might still be useful when you build a public JS API like Google Maps. True information hiding makes the interface much more explicit and enables you to change the internal representation of your objects later on without having to take care of people who relied it.

Monday, September 15, 2008

All Tests pass with JScript .NET

As of the last commit all Joose tests pass under JScript .NET.

What is not so nice is that JScript .NET wants to report an error to Microsoft every time you deference a non-existant property as a function. Oh, well.

Another interesting thing is that JScript .NET actually passes more tests than JScript. There is one unofficial feature in Joose that allows un-applying of roles which contain only method modifiers (yes, a plugin system on steroids!) at runtime. I haven't found a way to make this work under JScript, because it can only (easily) made to work with the __proto__ property which enables exchanging the prototype of a single object at runtime. Well, under JScript .NET there is no __proto__ property, but it still works. There must be something else going on in the background. Joose is also switching object.contructor to a new value and maybe .NET is using that path to find the object's prototype property?

Sunday, September 14, 2008

Joose now works with JScript .NET

I'll start a new job soon that will involve development with .NET so I figured it might be interesting to get Joose to work with JScript .NET.

Turns out, it works! Changes to Joose itself were minimal:
  • The .NET compiler actually spotted possible errors in Joose, which were easily corrected
  • While overriding toString seems to be possible, the JSC compiler complains about it when you do it too obvious :)
There was one more hurdle that was a little harder to take, but which might be also useful for other projects that get ported to JScript .NET:
Although there is a global object in JScript .NET, it doesn't have a name so you can't easily set new properties on it. Joose, however, wants to create new global objects when you make a module or class, so it needs this functionality. Turns out, it is quite easy to make it available:
When you execute a function declared in global scope, the 'this' variable refers to the global object, so you can assign that to a variable to make it available to the outside world. Here is a example that is using the name window for the global object (just like it is called in the browser):
var window;

(function() {
window = this;
})()
You are invited to try it out. You need to checkout Joose from SVN and then go to the directory playground/jscript.net/. The file test.bat will execute all the test files from the testsuite. You will need to have jsc (the JScript .NET compiler in your path) which is part of the .NET framework in your path.

There will be some crashes during the test run. These are all related to the JSON library which is used inside Joose.Storage. All other tests run though, so Joose should be very usable.

Wednesday, September 10, 2008

Joose "blutige Kante"

The test suite of Joose svn latest is now available at: http://joose-js.googlecode.com/svn/trunk/tests/test.html

Results welcome!

Refactoring Joose

One of the main features of the next Joose release will be the ability to make extending the class and role building syntax very easy.

Consider this example:
Class("MyClass", {
methods: {
...
},

primaryKey: "id"
})


primaryKey is not a regular property of the class builder. However, the class initializer will attempt to call the method handlePropprimaryKey on the meta class which can then do whatever it wants with the property.

This enables very declarative and special-case class construction styles.

While this has been in Joose for a couple of weeks, up until now there have been special cases for the "standard" class construction properties like "methods" and "has". As of this commit these special cases where completely eliminated.

Turning asyncronous interfaces into pseudo-synchronous interfaces...

... or making some callback-intensive JavaScript look less like bad LISP.

JooseX.DelayedExecution implements a type of mock object that implements the complete interface of the class object given to its constructor.
Every method call will schedule the method call with all its arguments for later execution on the original object.

This enables building asynchronous APIs that look like synchronous APIs.

Example:

This asynchronous code:
myFunc("foo", function (para) {
para.anotherFunc(function (para) {
para.yetAnotherFunc("bar")
})
})
can be turned into:
myFunc("foo").anotherFunc().yetAnotherFunc("bar")
by calling:
myFunc = function (para, callback) {
var result;
var process = function (result) {
delayed.__performOn(result)
}
... do something in an async callback that sets the variable result
return new JooseX.DelayedExecution(typeOfResult) // typeOfResult is the Joose class of the result object
}
I personally think that the latter is much more readable in certain circumstances. However, an unfortunate maintainer of the code might not know that the code is only hiding asynchronous execution which can lead to some hard to find bugs, because code is executed in random or at least async order.

For a use case of this technique, see the last post.

While this is probably so dangerous, that it should never be used, it was still fun to develop it.

Saturday, September 6, 2008

jQuery style result sets for OR-Mapper

I implemented a couple shortcuts that enable working with datasets in a jQuery style.

As an example, the sticky note code had a couple lines that looked like this:

Note.selectAll(function (notes) {
notes.each(function (note) {
note.redraw()
note.show()
})
})


The API is inherently asynchronous because that is the only way that is provided by the HTML5 database API.

This can now be written as:
Note.selectAll().draw().redraw().show()


This is pretty dark JavaScript magic going on, because all methods after selectAll won't really be executed until the select has actually been executed.
I like this API style much better, but it has some serious draw backs:
  • In the Gears version you loose the transaction context because evil global vars are involved (in my mock up implementation of the HTML5 api)
  • If there is something coming in the next line, one would expect it to be executed after show() which is not the case.

Tuesday, September 2, 2008

Joose is a featured project on Google Code

Joose was selected as a featured project on the Gears API page.
There is now a landing page on Joose's Google Code site that summarizes all the tools included in Joose that help with working with Gears.

Joose now has a logo