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'.
written at 18:47. (0 Comments, Permalink)
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.
written at 17:10. (0 Comments, Permalink)
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
end
The members are accessed like static members in Java:
Counter.increase()
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
private:
static Map bookDb()
end
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
private:
singleton Db
Map books()
end
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.
written at 12:18. (0 Comments, Permalink)