Monday, September 29, 2008

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

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 == truetrue>>> 0 == falsetrue

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.

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:

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.

New Example: ORM: A JavaScript OR-Mapper that supports transparent access to the HTML5 database and the Google Gears database.This also promoted Joose to become the featured project on Google Code for almost two weeks.

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

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

Thursday, September 18, 2008

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.

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

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

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.

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.

... 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.

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.

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 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.