1. One of major targets of Aurum is to simplify external DSL development, espectually Ruby external DSL.
2. Aurum uses incremental LALR(n) algorithm instead of the common used LALR(1)/Full LALR(n) algorithm. That means:
   
   •   Allowing the user to express grammars in a more intuitive mannar.
   •   Making it easier to handle complicated grammars. For exmaple, COBOL(LALR(2 or 3)), simplified nature language(LALR(3+)) and etc.
   •   Closer to Generalized LR in language recognizing but much more faster.
   •   Smaller parsing table comparing to Full LALR/LR(n) algorithm.
3. Aurum supports grammar reuse, and itslef'll be shipped with some pre-defined common structures. One of the pain points of external DSL is that you have to re-define lots of common structures, such as if statements, block structure and etc. With Aurum, you could simply reuse them.
4. Aurum uses a Ruby interal DSL as meta-language, and provides a generic lexer/parser as well. You could test your grammar by the comprehensive testing libraries Ruby has(you could even develop your lexer/parser in the TDD fashion).
5. As the name suggested, Aurum, the Latin word for Gold, is partially inspired by the GOLD Parsing System. The grammar you created with Aurum could be completely independent of any implementation language,even Ruby.(not implemented yet :) )

1. At point a, we use 'ignore' directive to declare the ignored pattern, such as whitespaces etc.'string' is one of the helper methods(others are enum, range and concat), which is used to define lexical patterns. It will create a pattern matching the given string exactly.
2. At point b, we declare a lexical token named '_number'. In Aurum, lexical tokens, or terminals from syntax perspective, always start with '_'. The expression '_token_name pattern' is equivalent to 'match pattern, :recognized => :_toke_name'. The 'match' directive is a common way to associate lexical action with leixcal pattern.
3. At point c, we declare operator precedences of the Expression grammar.The eariler the operators definied, the higher precedence they will have.
4. At point d, we declare syntax rules of Expression grammar. According to Aurum naming convention, all terminals should start with '_' while all nontermainls start with lower case alphabet character. String literals will be interpreted as reserve words, and added to lexer automatically.
5. At point e, we define a semantic action to the Addition rule. In semantic action, you could access to the objects in value stack via the name of corresponding symbols.If there are more than one symbol with the same name, you could differentiate them by the order they appered in the production.
6. At point f, we use do..end instead of {..}. Using Ruby internal DSL as meta-langauge is a double-side sword, you have to bear its flaws while enjoying the remaining parts. There is no perfect world, isn't it?

1. Annotating Description with @Embeddable, and the Thing it describe with @Entity

Take Product and ProductDescription for example.

 1@Embeddable
 2class ProductDescription {
 3 private String name;
 4 private String description;
 5  . and getters and setters
 6}
 7
 8@Entity(access = AccessType.FIELD)
 9class Product {
10
11 private ProdcutDescription description;
12
13}
14

In hiberante, we could make the ProductDescription as an embedded persistent object of Product via the component tag.If the ProductDescription should be embedded in another object, we've to declare it once more.
Things become more convenient in JSR 220, because non-transite fields, whose class is annoated with @Embeddable, are treated as embedded persistent objects automatically, we'd have fine-grained persistent objects without long-winded config file.

2.Avoiding Database Field in Domain Model Using @AttributeOverride

It's claimed that Annotaton could simplify development, but considering the cost of hard-coding mapping information in source codes I prefer some other complicated ways.It's too ugly to write code like following.

1@Entity(access = AccessType.FIELD)
2@Table(name="TAB_PRODUCT")
3class Product {
4
5   @Basic
6   @Column(name="NAME", nullable=false, length=512)
7   private String name;
8}

It's sucks but could be avoided.

 1@EmbeddableSuperclass
 2class Product {
 3
 4  @Basic
 5  private String name;
 6}
 7
 8@Entity
 9@AttributeOverride(name="name", column=@Column(name="Name"))
10@Table(name="TAB_PRODUCT")
11class PersistentProduct extends Product {
12}

We could separate the domain model and the persistent model by inheritance.Although we could do the same thing in hiberante too, we have to provide lots of configuration files.Once more we'd have hierachical persistent objects without long-winded config file.

3.Avoiding Database Primary Key in Domain Model

In most O/R mapping framework, we are always asked to give a primary key or identifier to our domain model, and we are suggested using meanless identifier instead of domain-specified identifer.It's kinda of Domain Pollution.Although we couldmake the domain model more clearer via inheritance, it's pointless for common usages.
Fortunately, we HAVE TO separate domain model and persistent model(as above mentioned), so that we can throw this bad habit away conviniently :D

1@EmbeddableSuperclass
2class Product {
3}
4
5@Entity
6class PersistentProduct extends Product{
7
8   @Id private long primaryKey;
9}

Conclusion

After two hours walking around JSR220 persistent API, I figured out that JSR220 mixed ugly into convenience... and it's quite easy to write ugly codes in jsr220...so that we've to insist on using OO and the convenience jsr220 provided to make our domain model as clear as possible.
Although JSR220 is more ugly than hibernate, we could get clearer domain model in jsr220 rather than hibernate, because we could not stand the unly in jsr220...weird way to make us keeping more OO...cool isn't it...

so, you think the consistent thing means a lot? But how do you think the gracious or elegant feeling mean to the real expressiveness of business requirements? We can see lisp is very successful in researching area because of the simplicity nature inside which is also true to Smalltalk. But why they aren't successful in biz world? I think that is the problem you should further study, "how can the consistent feeling mean something to our everyday programming life?".

First of all, I should admit that I'd never thought about this question before, becasuse I think hankering after consistent concepts is some nature of us. The question enlightens me to thinking deep. Here are my points.

1.Complexity

Inconsistent concepts bring complexity.I'll give two examples.

First one is something in Lisp. Lisp has a very simple computing model called λ Calculation. There are three elements in this computing model: Function, λ Operator and · Operator. λ Operator picks up free variable from the function, and · Operator applies the variable with a concrete value. The whole evaluation-application thing is what we called symbolic algebra in math.For example, if we've a function whose expression is x + y.

((λx (λy . x + y)·3)·4)
=((λx. x+3)·4)
=4 + 3
=7

Since Lisp is kinda implementation of λ Calculation in computer, we could do the same thing in Lisp (and its dialects).

(define f (lambda x (lambda y (+ x y))))
(apply (apply f 3) 4)

or we could use some syntax sugar

(define (f x y) (+ x y))
((f 3) 4)

Most of things in Lisp are focus on evaluation, and the evaluation should be done in a simple consistent way: evaluating, applying value and then returning the value without any change to enviroment. It is the very same way that we do something in math.
But variable assignment was introduced to Lisp, so some functions  which change enviroment instead of simple evaluating came to Lisp.For example:

(define (bad-f x y) 
  (begin 
     (set! z 5)
     (+ x y)))

That bad function changes value of symbol 'z' while evaluating x + y. It is the variable assignment which breaks the consistent concepts. The consistent concepts suggests that function should do and only do evaluation. We must find a more complicated computing model to replace the simple elegant mathematical one.Here inconsistent brings complexities in computing model.

The other example comes from Java. Java is considered to be an object-oriented programming language with single root type system. Conceptually speaking, everything should be an object.But for some perfermance reason, Java has some primitive types (such as int, double, float etc.) too.Those primitive types introduced a algebraic world which paralleled to the object world, and broke the consistent concepts.Althought Java has some wrapper classes for those primtive types, they are not enough for filling the gulf between object and algebra.
We could use new Integer(3) to represent 3 in object world, but we could not simply translate

3 + 4 * 5

to

new Integer(3) + new Integer(4) * new Integer(5)

Algebraic calculation and  object message sending are totally different. Although we could do that in Java 5, it also has lots of differences.Auto-boxing treats object as primitive instead of operator overloading in C++ which treats operator as object message sending.So in my opinion, auto-boxing in java5 is awful. Assginments and storage of primitive type and object have lots inconsistent semantics too. This inconsistent would bring complexity when we use Collection API(Remember Primitive Collection in Commons Collection Project? )

2. Side-Effect

The mainly cause of side-effect is  putting some inconsistent concepts together. I'll also give two examples.

First example is the well-known side-effect in functional programming, which is caused by mixing Von-Nouma-style-things into λ Calculation. There are lots of discussion about this topic in functional programming community.It's meanless to repeat that again.

Second example comes from half-blooded object-oriented languages, for we'll find both object-oriented things and procedure-oriented things in these languages, and it'll be much more easier to write code in procedural way instead of object-oriented way.For example, we'd write code like this:

1if (order.getState() == Order.CANCEL)
2   do something for cancel;
3else if(order.getState() == Order.PAID)
4   do something for paid;
5else if(order.getState() == Order.DELIVERY)
6   do something for delivery

 1public abstract OrderState {
 2
 3   protected Order _order;
 4   
 5   protected OrderState(Order order){
 6      _order = order;
 7   }
 8    
 9   public abstract void handler();
10}
11
12class CancelState extends OrderState {
13
14   public void handler() {
15      do something for cancel;
16   }
17}
18
19order.getState().handle();

 1Boolean>>ifTrue: alternativeBlock 
 2  self subclassResponsibility
 3
 4Boolean>>ifFalse: alternativeBlock
 5  self subclassResponsibility
 6
 7"and True and False are subclasses of Boolean."
 8
 9True>>ifTrue: alternativeBlock 
10  ^alternativeBlock value
11
12True>>ifFalse: alternativeBlock
13  ^nil
14
15False>>ifTrue: alternativeBlock 
16  ^nil
17
18False>>ifFalse: alternativeBlock
19  ^alternativeBlock value

and then in some codes, we could do the conditional execution as follows

14 > 3 ifTrue: [Transcript show: 'Hello']

In Smalltalk, everything is Object, so that the code above means sending a message named '>' to an Integer object, whose value is 4, with an Integer object parameter. And '>' would return a Boolean object, and then we sent a message  named 'ifTrue' to it. This is a typical usage of State Pattern. Here are the equivalent Java codes.

 1public class abstract Boolean {
 2   public static final TRUE = new True();
 3   public static final FALSE = new False();
 4
 5   public abstract Object ifTrue(Block aBlock);
 6   public abstract Object ifFalse(Block aBlock);
 7}
 8
 9class True extends Boolean {
10
11   public Object ifTrue(Block aBlock) {
12       return aBlock.execute();
13   }
14
15   public Object ifFalse(Block aBlock) {
16       return null;
17   }
18}
19
20class False extends Boolean {
21
22   public Object ifTrue(Block aBlock) {
23       return null;
24   }
25
26   public Object ifFalse(Block aBlock) {
27       return aBlock.execute();       
28   }
29}
30
31public class Integer{
32  
33   public Boolean greaterThan(Integer anInteger) {
34      
35   }
36}
37

14 〉3 ifTrue: [Transcript show: 'Hello']

which could be translated in Java like this:

new Integer(4).isGreaterThan(new Integer(3)).ifTrue(new BlockClosure() {

   public Object value() {
      System.out.println("Hello");
      return null;
   }

});

That's quite simple(some dynamic languages on JVM ,e.g. Groovy, do the same thing), but it indeed brings some profound changes to my thought.

First, considering that 'if'，'for' and 'while' are no longer pre-defined keywords, we could define our own control structures. For example, we could define Order has its own way to do something.

 

1anOrder ifExpired: [ do reactive order]
2        ifCanceled: [do something else]

 

Taking no account of performance and semantic speaking, there is no difference between the code above and undermentioned:

 

1   4 >3 ifTrue: [do something]
2        ifFalse: [do somthing]

 

More fancy, we could define a new test structure like this:

 

1anOrderTest should: [some assert] when: [do some initalize].

 

So we could have programmable control structure in Smalltalk ( something like we do in Lisp via continuation:) ), and define our own DSL easily.That's the amazing lightweight syntax feature in Smalltalk!

 

Second, we could get full capability of Von Nouma Style Programming Language via pure OO concepts.We could construct software in consistent OO concepts.

 

I began my adventure in Object technology by using C++ in 1995, and then I chose Java as my main working language. All my experiences about OO come from half-blooded OO language.So that for a long time, I thought Object-Oriented Programming is a big patch to imperative languages. The imperative languages are desgined  to record the sequence of instruments which are used to manipulate the computer, so they are lack in semantic, and poor in abstraction. Though the Object technology introduces a successful type system and provides some abstraction mechanism, I still feel sucks to program in inconsistent concepts, because I should be careful about keeping programming more in OO-style rather than in procedural-style(something like Domina Model or not, sucks!).

Once I accused Object-Oriented Methodology of all the fault, I blamed imperfection on Object-Oriented Methodology.But now, I found out it's only because that I have little talent and learning in OO, it turned out to be my fault, I should say sorry to Object-Oriented Methodology.