Thanks Nicolas. Comments inlined.
On 11 Feb 2011, at 17:14, Nicolas Anquetil wrote:
There are still open issues, and it would also be great to get help on them:
- How to model the parameters of a ParameterizableClass as a Type that
can be used as declaredType. We should add some sort of a local scope to a type. See: http://code.google.com/p/moose-technology/issues/detail?id=495
I would say that ParameterizedClass has a list of parameter types (here:
This is the ParameterizableClass not the ParameterizedClass.
class Mymap<K,T>
and each type (ex: K or T) could be defined more or less as we define inner classes: a class within the scope of another class (MyMap here).
Right. So, I introduced ParameterType subclassing Type that has as container the ParameterizableClass. The ParameterizableClass computes the parameters as follows:
parameters <MSEProperty: #parameters type: #FAMIXParameterType> <multivalued> <derived> <MSEComment: 'Parameter types of this class.'> ^self types select: [:each | each isParameterType]
The nice thing about having the ParameterType as contained in the ParameterizableClass is that we have scoping. The not so nice thing is that we have to traverse the inner types to get to the parameters, and now we will also have to take care of distinguishing innerClasses from the parameterType.
Another option would be to override the meaning of container in ParameterType and have its opposite the parameters, rather than the types property of ParameterizableClass.
Any opinions?
Parameters may have a super class (not sure of the exact Java syntax here), but this would be handled normally:
class MyMap<K implements Integer,T>
The problem is in the use of the ParameterizedClass, when we specify (possibly partially) what are the parameters to use.
MyMap<Integer,Object> aMap;
This is now achieved via a ParameterizedType. This in turn has arguments as a collection of Types.
This would suggest a new association (Reference, Inheritance) where one would specify the parameters of the ParameterizedClass. Not very satisfying but I couldn't think of any better solution. The association would have a list of parameters where order is significant (the same as in the ParameterizedClass). The actual parameters in the Reference could be "real" ("concrete") types or new parameter types if we specify only partially the parameters:
class MyStringMap<T> implements MyMap<String,T> ...
Since Interfaces may also be parameterized, we may want to raise all this at the level of Types (ParameterizedType) instead of classes. Or may be we can use Traits?
Well, the current solution is that interfaces are modeled as FAMIXClass with an isInterface flag. FAMIXParameterizableClass being a subclass of FAMIXClass will be able to model an interface in the same way.
However, I still think it would be nice to have FAMIXInterface explicitly. It would make it easier to clarify the meaning of MooseModel>>allClasses which right now is a bit confusing. So, yes, I think that traits would be an interesting choice.
Any comments?
Cheers, Doru
nicolas
- I would like to have an explicit FAMIXInterface, but it is slightly
more difficult now that we have ParameterizableClass. See: http://code.google.com/p/moose-technology/issues/detail?id=526
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."