Still not done...
Ok, I admit it, I am still not done. There are 7 pages left which contain only stubs right now (Exceptions, Constraints, Delegates, Closures, Events, EXML and the tokenizer) and I hope to have them soon.
I am also considering 3 syntax changes at the moment:
- Removing the special notation for invoking delegates. There is no need for it, a delegate with the signature "delegate(String):int" is just a name for an interface that extends the IDelegate interface and adds a method "call(String):int". "call" is the identifier of the method, and the only magic of delegates in Eek is that Eek makes a compile-time guarantee that a delegate has a method named "call" with delegate's signature. So why not simply invoke "call()"? I do remember that examples of C# with its delegate invocation syntax confused me when I first saw them; delegates are not invoked that often, and so I think I can just live without it.
- Changing the syntax for generics/class parameters. Right now, all class parameters are specified in angle brackets ("<>"), but I never really liked using relational characters as brackets, even if C++ and now Java do. The clean alternative would be to use regular brackets ("[]", do they have any special name?):
class Stack[Object T]
private Array[T] mArray
push(T obj)
// ...
pop(): T
// ...
// ...
add[Number T](T a, T b): T
return a + b
// ...
delegate[Number T](T,T):T myGenericDelegate = closure[Number T](T a,T b):T { a + b }
It may take a while to get used to it, but it's easier to type and to read. - To avoid confusion, I would then replace the index operator ("[]", the one used to access arrays in C++ and Java) with the 'at' char. So instead of "x[4]" I would write "x@4" to access the fourth element. It is not as nice to write and read as brackets, but I expect the index operator in Eek to be far less frequently used than class parameters.
written at 01:47. (0 Comments, Permalink)