« | Main | »

JewelScript changes log

By Jewe | March 14, 2010

This post lists all changes made to the project since it’s previous public release, version The most recent change is at the top of this post.

fixed serious bug when generating default implementation of cofunction

When a function or cofunction has been declared, but not defined, the linker will create a default implementation for you, to make sure the function exists in case it is being called from the native side. There was a bug that did not create the correct code for declared cofunctions. This has been fixed.

fixed rare compiler bug

A rarely occurring compiler bug has been fixed that prevented a native type from being imported by the import statement and caused a “Fatal Error” compiler condition.

added pure native interfaces

It is now possible to declare interfaces using the “native” modifier keyword. This will make the interface pure native, meaning script classes can not implement this interface.

Originally, the general idea of interfaces in JewelScript was, that it doesn’t matter if the class implementing them is native or written in script. If you use the JewelScript API to call an interface method, it doesn’t matter if this method belongs to a class written in C/C++ or JewelScript. However, I have noticed that this transparency is not always what you want, and it is not always feasible to use the JewelScript API in order to call a method of your native class. Sometimes, you just want to get a native pointer to your object and make a direct call to it’s methods. While you always had the option of doing that, there was a slight problem. Script programmers had no knowledge whether an interface was intended only for native classes or not. So you could end up trying to pass an object implemented in script to a function expecting only native objects – since it wants to call them directly. This of course would fail.

And this is where the native interface declaration comes in. By declaring your interfaces pure native, you can make script programmers aware that this interface is not meant to be implemented in script code, and the compiler can ensure that you cannot pass a script object to a function that cannot handle the object.

lots of improvements to built-in C/C++ binding code generator

The binding code generator has gotten a makeover. The main changes are the inclusion of the new features, such as the documentation tags. Also, your native C++ class is now instantiated using the C++ placement new operator. This eliminates the need for implementing “operator =” in your class. Your C++ object is no longer unnecessarily copied in the JewelScript constructor code.

added HTML documentation engine, XML type export

There now is a HTML documenation generator in the library. It will document all classes that are currently “known” to the compiler and contain tags. In addition, the compiler will export all known types to an XML file. This gives people the opportunity to come up with a more advanced report or documentation generation tool. It could also be used in a source code editor / IDE to get a complete XML model of the program currently being developed.

You can see an example of the output generated by the HTML documentation generator here.

I’d like to emphasize that both the HTML documentation generator and the XML exporter are completely ANSI C compliant, and require no external tools or libraries. They are handcrafted using only the string functions of the JewelScript compiler.

added “tags” to the language

It is now possible to add a tag to a function, class or interface declaration. The tag will be stored by the compiler and included in the xml export and html documentation. The main purpose of the tag, for now, is to add documentation to the language construct. There might be other uses in the future as well.
Here is a code example:

class Hello
    ["This is a documentation tag for class Hello."]
    method Hello();         ["This is a documentation tag for the constructor"]
    function int Test(int); ["This is a documentation tag for function Test()."]

hybrid and interface

A compiler bug has been fixed that prevented you from using the hybrid keyword together with an interface identifier.

interface IFoo { }
class Foo hybrid IFoo    // did not compile

Creating a hybrid class from an interface can be quite useful, so this has now been fixed.

operator typeof and this

A compiler bug has been fixed that prevented the expression typeof(this) to compile.

class Foo
    method Foo() { }
    method int GetType() { return typeof(this); }    // did not compile

Topics: docs | Comments Off on JewelScript changes log

Comments are closed.