[DotGNU]C@ design goals (was: Re: Doubts about C@)

[Peter Minten]

Gopal V wrote:

> Aspect Oriented programming is already possible in C# using treecc,
> but that is more towards the compiler design model ... I guess a
> AspectJ like compiler for C# won't be amiss here ...

IMHO C@ is about as much like AspectJ as GNU is like Unix, it may do the same
things but on the inside it's something completely different. I know people
expect C@ to do the same and look the same as AspectJ, but I hope it won't. This
is because I want to avoid the problems of AspectJ.


AspectJ is certainly a good language but I see a couple of problems in it that
probably result from trying to build the best AOP language possible. The first
is complicatedness, the syntax of the language is hard to learn because it
differs from what you would expect. For example:

'pointcut testEquality(Point p):
     target(Point) && args(p) && call(boolean equals(Object));'.

This means: testEquality has a parameter p that is the Object past to method
equals cast into a Point, to activate this pointcut the object containing equals
must be of type Point.

Now compare the code in C@ that does the same as the AspectJ statement:

'pointcut testEquality (Point p) = call("bool equals(Object p)") && target is
Point;'.

What you see here is that the p on the left side seems to be the argument of the
equal function on the right side and that the target must be a point,
a lot clearer IMHO.


The other problem I see is the overuse of keywords. For example conflicts
created because of introduction of new members/methods into a class are resolved
using a keyword, I'd say that a programmer shouldn't create a conflict situation
and thus should get a compile error. This wouldn't be such a problem if keywords
wouldn't have disadvantages: it's hard to implement a keyword for the programmer
(thus it will take much longer to create a language with many keywords and there
would be more bugs in the language) and keywords create rules (every keyword can
be used only in specific situations so a programmer must learn these situations
and also the way to use the keyword).

My approach to such matters is to create keywords that can be used to do more
than one task (for example the 'substitute' keyword discussed in another mail).
This gives the programmer less to learn (more to think though, but that's
usually not a problem :-).


In conclusion these are my design goals for C@:
* Simplicity (keeping the language out of the way of the programmer)
* Usability (having lot's of useful functions in the language)

These are not necessarily *the* design goals for C@, they're just my design
goals. But if everybody agrees with them I'd like to make them the official
design goals.


A few syntaxic notes:
AspectJ pointcuts have such a form
'pointcut stuff(params) : designator connector designator connector designator;'
where designator is something like call(signature) or if(expression) and
connector is either || or &&. Any number of if() parts can be in a pointcut.

C@ pointcuts have the form:
'pointcut stuff(params) = expression connector expression connector expression;'
All designators is treated as a methods returning a bool (I guess AspectJ does
this too). The whole right hand side of the statement is an expression. As a
consequence C@ uses the || and && and ! operators just like AspectJ. But
where AspectJ uses special designators to check for args and type of the called
object, C@ uses a more natural syntax. As a result there is no 'if' designator 
in address@hidden Note that 'target' is a special variable in pointcuts, it 
refers to the 
object being called.

Btw: I'm wondering what would be the most natural syntax for the designators:
designator{stuff} or designator(stuff) or designator("stuff"). The {} designator
seems a bit illogical, the () designator would look like it accepts bogus 
arguments. But the ("") designator costs programmers 2 extra character every 
time they use it, however I think it looks most natural.

Examples:
'pointcut testEquality (Point p) = call{bool equals(Object p)} 
  && target is Point;'.
'pointcut testEquality (Point p) = call(bool equals(Object p)) 
  && target is Point;'.
'pointcut testEquality (Point p) = call("bool equals(Object p)") 
  && target is Point;'.

Greetings,

Peter