« | Main | »

JewelScript changes log

By Jewe | January 11, 2015

This post lists all changes made to the project since it’s previous public release, version The newest change is on top of the list.

New Features


Local anonymous functions and methods are now closures. A closure is a function that can directly access it’s parent function’s local variables — even after the parent function has returned.

This makes local anonymous delegates much easier to use, since you no longer have to pass additional data to your local delegate as function argument. It also allows other interesting uses.

As a result, all built-in types now have an overload for the enumerate() function that doesn’t accept a second ‘args’ parameter.

See this post for more information on closures.

Multiple inheritance, “mix-in classes”

JewelScript now supports multiple inheritance. The keyword inherits allows you to inherit code and variables from multiple base classes.

However, there are some restrictions in place. JewelScript doesn’t support polymorphism — and never will, as it is my experience (and not mine alone) that polymorphism creates more problems than it’s usefulness solves. There are better, less error prone and easier to manage ways to create polymorphic objects — for example by simply adding base instances as variables to your class.

JewelScript’s multi-inheritance allows you to “mix-in” code and variables from base classes into your new class. This allows you to implement interface methods or override base class methods from a set of predefined implementations.

If you’re familiar with the C++ standard template library (STL) and it’s policy classes, you can understand this as the model for JewelScript’s mix-in classes: By inheriting certain base classes you can customize how the main class performs certain tasks — for example how new objects are allocated, how objects in a container are accessed, and so on.

See this post for more information on multiple inheritance.

Fully featured single inheritance

Keyword extends allows to extend any script class, override any method, call any base member and access any base variable, unless they have been made private.

Method calls are static by default, but can be made virtual by declaring the method or entire class virtual.

See this post for more information on single inheritance and virtual methods.

See Let’s talk ‘private’ on making class members private.

New built-in type ‘arraylist’

I have added a new built-in type to the runtime: arraylist. The class is a compromise between the flexibility of a list and the efficiency of an array.

It is very fast when accessing items by their index. Adding and removing items is not as quick, but it is still a good alternative to the built-in list class.

Like all built-in classes (except runtime) you do not have to import this class. It is always available when you initialize the compiler.

Relaxed property / variable name handling

You want to add a member to your “Control” class that returns it’s size, but you can’t use “Size”, because that’s already a type. You want to add a member “Rectangle” to it, but that’s already a type name, too. Sound familiar?

I was getting tired of this, especially after seeing how C# handles this so gracefully. So I modified JewelScript’s checking of duplicate identifiers and expression parsing.

As a result, you can now use variable names and property names that have the same name as the type they return. Because the compiler (and you too) are smart enough to distinguish these names by the way they are used.

class Control
    Rectangle Rectangle;
        |        |
       type    variable

    method Control()
        Rectangle = Rectangle::FromSize(100, 10);
                  |           |
               variable      type

        int w = Rectangle.Width;

Added weak cast operator

Declaring variables as weak reference proved to create more problems than it was supposed to solve, therefore doing that is now discouraged and will generate a warning.

Instead, the weak cast operator has been introduced into the language. This operator lets you create a weak reference from any value when needed.

Read all about this topic in I get weak in the presence of weak references.

Added new API function: NTLSetTypeUserData()

Native types always had the option to attach any user pointer to their instance. This was mainly intended for cases where a native type needed to allocate some ‘semi-global’ storage for additional variables. This is important, because an application may create multiple instances of the runtime, so native types must NEVER use global variables.

The API functions NTLInstanceSetUser() and NTLInstanceGetUser() allow a native type to access this user pointer internally. However, there was no way how an application could access this user data pointer externally.

This has been changed. NTLSetTypeUserData() allows the application to attach any pointer to any native type that has been imported. This allows developers to create native types that appear like global functions in JewelScript, but internally call methods of a C++ object. Simply attach the C++ instance as user pointer to the type and have the binding code retrieve and call that pointer.

Added new API function: JILMessageLog()

I have revised several areas of the runtime that used FILE handles to output information. To have a clean, generalized behavior across the library, all functions that output something, now use the official message logging callback of the runtime.

To allow the application side to use this logging callback too, I have added the API function JILMessageLog(). It uses the same variable arguments as the standard C printf() function.

This is useful if you want to write all output from the compiler and runtime into a log file. JILMessageLog() will allow your application to send text into the log file as well.

The function JILOutputCrashLog() has been added to allow generating a detailed crash log. Developers can call this function anytime to output the state of the VM. The function lists current instruction, call stack, registers, data stack and the byte-code of the current function.

Added more runtime checks

Last but not least, I have decided to sacrifice a little of the virtual machine’s performance for improved error detection. Especially the null-reference exception — probably the number one runtime error to expect — was only detected in debug builds of the VM (or if you enabled extended runtime checks for release builds).

All method calls and accesses to object members now check for null-references and generate an exception if necessary. This causes an insignificant drop in execution speed, but it greatly improves error detection and protects the application from crashing in most cases.

Topics: docs | Comments Off on JewelScript changes log

Comments are closed.