13 Feb
2011
13 Feb
'11
6:22 p.m.
Thanks Nicolas. Comments inlined.
On 11 Feb 2011, at 17:14, Nicolas Anquetil wrote:
This is the ParameterizableClass not the ParameterizedClass.
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: 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
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
- 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev