Tim Jansen's blog

Simplifying Access Controls
After getting rid of 'static' members, I am currently watching for other C++/Java legacies that I could get rid of. And I found access controls. Until today, Eek used a C++ label syntax with C++'s 'private/protected/public' modes and additionally 'protected api' and 'public api'. The new modes were needed to make a member accessible to other assemblies. This became much too complicated, but because I think that the 'api' modes are important, I decided to drop the rarely used 'protected' modes. 'protected' can be useful sometimes, but most of the time it is just bad API design that tries to combine extensibility and real functionality into a single interface. The remaining modes were 'private', 'public' and 'api'. Because 'public' was already default, I switched from a C++ label system to a Java modifier system and got rid of 'public' as well. A member without a modifier is 'public', and the remaining access control modifiers are 'private' and 'api'.

Transition to Mediawiki
I have decided to move the Eek documentation from MoinMoin to Mediawiki. I was always frustrated by MoinMoin's lack of features, and as I wrote many Wikipedia contributions in the last weeks, I got so used to Mediawiki's syntax that I do not want to miss it any longer. The installation was easier than expected, and now I have a fresh Mediawiki running. The next step will be to port the MoinMoin content to the other syntax, get rid of the CamelCase and so on. When doing this revision, I am also going to get rid of static members and to add generics/class parameters.

OOP without static/class members
In the last month, the progress on Eek was really slow. But I am about to do a major change in the language specification. Until now Eek supported static method and property members in classes, like all other OOP languages that I know. I never liked having two different kind of members, and it also makes the specification more complicated. This week I found an equivalent feature that allows me to get rid of static members and is even simpler: 'singleton' classes. 'singleton' is a special kind of class and is declared exactly like a 'class' or 'interface', just with the 'singleton' keyword. The difference between a 'class' and a 'singleton' is that there is never more than one instance of the singleton. You can retrieve a reference to the instance by using the class name like a variable in an expression. Thus the syntax for accessing a singleton's member is exactly like using a static member. Singletons can have only one (optional) constructor which must not have any arguments. When the instance is requested for the first time, this constructor is called, so it also replaces the need for class constructors. The following code shows a simple counter as singleton:
singleton Counter
        int value

        int increase()
                return value += 1
The members are accessed like static members in Java:
Console.println("The counter value is now {Counter.value}.")
Singletons can do everything that static members can do. The next example shows how to implement a simple database of books with static members:
class Book
        int isbn
        String name

        static Book(int isbn, String name)
                if bookDb.contains(isbn)
                        return bookDb[isbn]
                Book b(isbn: isbn, name: name)
                bookDb[isbn] = b
                return b
        static Map bookDb()
The example has two static elements: a static constructor and a static property 'bookDb'. Static constructor will still exist with singletons, I just rename them to 'factory'. They have the invocation syntax of regular constructors, but work like static methods. Now here is the example with a 'singleton' and using the 'factory' keyword:
class Book
        int isbn
        String name

        factory Book(int isbn, String name)
                if Db.books.contains(isbn)
                        return Db.books[isbn]
                Book b(isbn: isbn, name: name)
                Db.books[isbn] = b
                return b
        singleton Db
                Map books()
The code is a little bit longer, because the singleton members are prefixed with the class name. If this should really become a problem, I can still allow accessing members of inner class singletons without this qualification. But right now I hope that it is not necessary. The 'factory' also has a problem: it does have an instance and thus 'this' would not valid. This is exactly what I wanted to avoid when removing static methods. So I need a small trick: the factory methods of a class will be put into some (anonymous) dummy singleton inner class. So 'this' will be valid object, just a useless one. I am thinking about the 'singleton' concept since monday, and I am quite happy about it. It will take some work to get it into the specification, but i hope that it will simplify the specs in some places.


This blog is my dumping ground for thoughts and ideas about Eek. Someday Eek will be a programming language and system, somewhat comparable to Java in scope. It is my attempt to bring sanity to the world of computing.
At least I hope so. Right now it is far from being finished and I can't guarantee that it ever will be. I am still working on the specification, but I won't release anything before I got my first prototype running. The world does not need more vapourware and unusable beta-software. All publicly available information about Eek is contained in this blog. You can find the latest summary here.
This page is powered by Blogger. Isn't yours? Creative Commons License
This work is licensed under a Creative Commons License.