Why Kermeta doesn't have constructors ?

We have quite a few questions about constructors these days so here is the reason why they were not included in Kermeta in the first place and some thoughts about how Kermeta could evolve.

In OO programming constructors are pretty useful but there are no constructors in Kermeta (yet). Constructors do not exist in MOF so any MOF compliant class can be instantiated as soon as it is defined. The semantics of this instantiation does not involve any customizable behaviors. If we add constructors to Kermeta the instantiation of a class from Kermeta and from another MOF tool (such as the EMF reflective editor) will not result in the same object.
It was not a problem to add operation redefinitions and to choose a semantics for operation call because MOF does not say much about it (In the EMF reflective editor it is impossible to call an operation). But MOF specifies explicitly the instantiation mechanism so to remain fully-compliant we decided not to add constructors. I think this was a good choice for the first versions but something is clearly missing now. Several options might be interesting :

1) Regular constructors : We could break the MOF compliance of Kermeta on this. This would probably not cause much compatibility issue for now but I don't think it is a good idea to step away from MOF.

2) Default values for properties : MOF defines the notion of default value but we haven't implement anything about it in Keremeta. This might be an answer to some initialization problems. Even if it is not a solution for replacing constructors we should probably implement it just because it is in MOF.

3) "Not mandatory" constructors : We could add constructor but keep a  MOF compliant instancition mechanism.  There would then be two possibilities for creating objects in Kermeta : by calling the MOF::Class new operation (as it is now) or by calling a constructor.
A general way of implementing something that look like this would be to add class operations to Kermeta (static methods in the JAVA terminology). This is another discussion but like for constructor I think it was a good thing to start without "statics" but kermeta programmers (including me) have identified a need for such a mechanism. This should not break the compatibility with MOF because in MOF operation are not defined neither as instance operation nor class operations they are just "operations". Using class operations we could implement something like a constructor, here is an example :

// the definition of a class user
//***********************
class User {

   attribute name : String

   // a class operation that will be used a some kind of constructor
   class operation create(n : String) : User is do
      // create the object
      result := User.new
      // initialize it
      result.name := n
   end
}

// now for some client code :
//***********************
// I can still create objects in the MOF sense :
var u1 : User init User.new
// Or I can use the class operation
var u2 : User init User.create("toto")

I like this solution because it is in the spirit of Kermeta: including general mechanisms instead of specific construction.

To sum up I started talking about constructors and now I am saying that we should have default values to be fully MOF and class operations as a more general mechanism. Sorry if it is not clear....

What do you think about these options and do you see any other solutions ? We are probably not going to implement this in the next few months but it is interesting to start thinking about it and this way we can provide our users (especially my homonym :-)) with better answers.

Cheers,

Franck F.