new java support in famix
Locked
 
|
Hi,
As you might have noticed, we have new additions to Famix-Java: - ParameterizableClass and ParameterizedType (to model generics and templates - thanks Andre :)) - Enum and EnumValue (to model Java Enums) - AnnotationTypeProperty and AnnotationInstanceProperty (to have detailed information about AnnotationType and AnnotationInstance) I am currently working with the inFusion guys to get the exporter working with these new additions. It would be great to have also VerveineJ up to date on this. 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 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 Cheers, Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: new java support in famix
|
|
Doru
I do not really understand why you do not help fixing verveineJ since it is MIT/BSD and that for us inFusion is still closed code. What is the logic behind duplicating effort? Stef On Feb 10, 2011, at 10:14 AM, Tudor Girba wrote: > Hi, > > As you might have noticed, we have new additions to Famix-Java: > - ParameterizableClass and ParameterizedType (to model generics and templates - thanks Andre :)) > - Enum and EnumValue (to model Java Enums) > - AnnotationTypeProperty and AnnotationInstanceProperty (to have detailed information about AnnotationType and AnnotationInstance) > > I am currently working with the inFusion guys to get the exporter working with these new additions. It would be great to have also VerveineJ up to date on this. > > 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 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 > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Stef,
The logic is extremely simple: They are investing the development effort. I am simply answering questions and reviewing the results. Moreover, their parser also supports C/C++ now, so that alone is a huge plus. I did the same with VerveineJ and I would still like to work with someone on this topic. Cheers, Doru On 10 Feb 2011, at 20:55, Stéphane Ducasse wrote: > Doru > > I do not really understand why you do not help fixing verveineJ since it is MIT/BSD and > that for us inFusion is still closed code. > What is the logic behind duplicating effort? > Stef > > On Feb 10, 2011, at 10:14 AM, Tudor Girba wrote: > >> Hi, >> >> As you might have noticed, we have new additions to Famix-Java: >> - ParameterizableClass and ParameterizedType (to model generics and templates - thanks Andre :)) >> - Enum and EnumValue (to model Java Enums) >> - AnnotationTypeProperty and AnnotationInstanceProperty (to have detailed information about AnnotationType and AnnotationInstance) >> >> I am currently working with the inFusion guys to get the exporter working with these new additions. It would be great to have also VerveineJ up to date on this. >> >> 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 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 >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: new java support in famix
|
|
ok
> Hi Stef, > > The logic is extremely simple: They are investing the development effort. I am simply answering questions and reviewing the results. Moreover, their parser also supports C/C++ now, so that alone is a huge plus. indeed. > I did the same with VerveineJ and I would still like to work with someone on this topic. > > Cheers, > Doru > > > On 10 Feb 2011, at 20:55, Stéphane Ducasse wrote: > >> Doru >> >> I do not really understand why you do not help fixing verveineJ since it is MIT/BSD and >> that for us inFusion is still closed code. >> What is the logic behind duplicating effort? >> Stef >> >> On Feb 10, 2011, at 10:14 AM, Tudor Girba wrote: >> >>> Hi, >>> >>> As you might have noticed, we have new additions to Famix-Java: >>> - ParameterizableClass and ParameterizedType (to model generics and templates - thanks Andre :)) >>> - Enum and EnumValue (to model Java Enums) >>> - AnnotationTypeProperty and AnnotationInstanceProperty (to have detailed information about AnnotationType and AnnotationInstance) >>> >>> I am currently working with the inFusion guys to get the exporter working with these new additions. It would be great to have also VerveineJ up to date on this. >>> >>> 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 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 >>> >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: new java support in famix
|
|
VerveineC has been on my todo list for a long time. It could work for C, but I still have problem with the C++ parser of CDT (I plan to use CDT for VerveineC just as we are using JDT for VerveineJ). I almost started it yesterday, but then I was abruptly remembered that there was a day long meeting at INRIA. Andre could work on enums for VerveineJ, it should not take more than half a day. ParameterizableClass and ParameterizedType are already there I believe. I am not sure what work is involved in AnnotationTypeProperty and AnnotationInstanceProperty? As for the two open questions, we just need some TIME to think about it. The very thing we all have in vast amount, ready to be spent at will :-) nicolas > > The logic is extremely simple: They are investing the development > > effort. I am simply answering questions and reviewing the results. > > Moreover, their parser also supports C/C++ now, so that alone is a > > huge plus. > > indeed. > > > I did the same with VerveineJ and I would still like to work with > > someone on this topic. > > > > Cheers, > > Doru > > > > > > On 10 Feb 2011, at 20:55, Stéphane Ducasse wrote: > > > >> Doru > >> > >> I do not really understand why you do not help fixing verveineJ > >> since it is MIT/BSD and > >> that for us inFusion is still closed code. > >> What is the logic behind duplicating effort? > >> Stef > >> > >> On Feb 10, 2011, at 10:14 AM, Tudor Girba wrote: > >> > >>> Hi, > >>> > >>> As you might have noticed, we have new additions to Famix-Java: > >>> - ParameterizableClass and ParameterizedType (to model generics > >>> and templates - thanks Andre :)) > >>> - Enum and EnumValue (to model Java Enums) > >>> - AnnotationTypeProperty and AnnotationInstanceProperty (to have > >>> detailed information about AnnotationType and AnnotationInstance) > >>> > >>> I am currently working with the inFusion guys to get the exporter > >>> working with these new additions. It would be great to have also > >>> VerveineJ up to date on this. > >>> > >>> 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 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 > >>> > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Be rather willing to give than demanding to get." > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > www.tudorgirba.com > > > > "Not knowing how to do something is not an argument for how it > > cannot be done." > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Nicolas,
I would suggest to first focus on getting VerveineJ working fully before embarking into another large project like the VerveineC. The problem with parsers is that if they are not working in edge cases they end up being unused. So, let's start a focused work on this to get it tested and scalable. Cheers, Doru On 11 Feb 2011, at 10:04, Nicolas Anquetil wrote: > VerveineC has been on my todo list for a long time. It could work for C, but I still have problem with the C++ parser of CDT (I plan to use CDT for VerveineC just as we are using JDT for VerveineJ). I almost started it yesterday, but then I was abruptly remembered that there was a day long meeting at INRIA. > > > Andre could work on enums for VerveineJ, it should not take more than half a day. > ParameterizableClass and ParameterizedType are already there I believe. > I am not sure what work is involved in AnnotationTypeProperty and AnnotationInstanceProperty? > > As for the two open questions, we just need some TIME to think about it. The very thing we all have in vast amount, ready to be spent at will :-) > > nicolas > >>> The logic is extremely simple: They are investing the development >>> effort. I am simply answering questions and reviewing the results. >>> Moreover, their parser also supports C/C++ now, so that alone is a >>> huge plus. >> >> indeed. >> >>> I did the same with VerveineJ and I would still like to work with >>> someone on this topic. >>> >>> Cheers, >>> Doru >>> >>> >>> On 10 Feb 2011, at 20:55, Stéphane Ducasse wrote: >>> >>>> Doru >>>> >>>> I do not really understand why you do not help fixing verveineJ >>>> since it is MIT/BSD and >>>> that for us inFusion is still closed code. >>>> What is the logic behind duplicating effort? >>>> Stef >>>> >>>> On Feb 10, 2011, at 10:14 AM, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> As you might have noticed, we have new additions to Famix-Java: >>>>> - ParameterizableClass and ParameterizedType (to model generics >>>>> and templates - thanks Andre :)) >>>>> - Enum and EnumValue (to model Java Enums) >>>>> - AnnotationTypeProperty and AnnotationInstanceProperty (to have >>>>> detailed information about AnnotationType and AnnotationInstance) >>>>> >>>>> I am currently working with the inFusion guys to get the exporter >>>>> working with these new additions. It would be great to have also >>>>> VerveineJ up to date on this. >>>>> >>>>> 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 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 >>>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Be rather willing to give than demanding to get." >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Not knowing how to do something is not an argument for how it >>> cannot be done." >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
OK Nicolas, I will check enums for VerveineJ next week.
ParameterizableClass and ParameterizedType are not in VerveineJ. What we have in VerveineJ is the "old solution" using parameterTypes/argumentTypes. I will check this too. regards, On Fri, Feb 11, 2011 at 10:16 AM, Tudor Girba <[hidden email]> wrote: Hi Nicolas, -- Andre Hora _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: new java support in famix
|
|
In reply to this post by Tudor Girba
> 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). 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 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? 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: new java support in famix
|
|
> >> - 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. Traversing the inner types should not be too much work. This is a feature does is not very much used. Same thing for ParameterTypes. It does seem a pain to have to test all the time to distinguish innerClasses from ParameterTypes. May be we can just make "parameters" an independent list to contain the parameterTypes? > 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? My general opinion is that overriding implementation is fine, overriding intent is a bad idea. Once one understood what a method is supposed to do or what an attribute means, one should not have to care what class one is looking at to know if this knowledge is still valid or not. So I would consider changing the meaning of "container" with a lot of care and currently I think it is probably a not-so-good idea. On the other way, the question is: what would be the meaning of "container" for ParameterType if we wanted to stick to the "normal" definition of container? And may be the answer is the ParameterizableClass? I am not too sure. Let's see it from another angle: Currently, the opposite of "container" is "types" defined as "Types contained (declared) in this entity" so can we say that a ParameterType is _declared_ in the ParameterizableClass? Maybe we should reconsider altogether the idea of defining ParameterType as a subclass of Type? Maybe we should set it apart just as AnnotationType? [ Actually, this raises another unrelated question: Why is AnnotationType not a subclass of Type? (I am looking at an image from 21/01/2011) ] > > 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. Not sure how this work? You mean for the use of a ParameterizableType, you define a new ParameterizedType that links back to its ParameterizableType and defines the ParameterType-s it uses? And what is the container of ParameterizedType? And its superclass? This is an idea I had too, but somehow I found that _declaring_ a new type when you want only to _use_ an existing type (and give it some parameters) was a bit outstretched, so I rather came with the new associations. I was not sure which solution is the less worse (less worst?!? less bad?!?). I am still not sure. > > 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? Again, we can go back to the bases: I teach to my student that when they implement a "type" attribute to avoid defining sub-classes they should think really hard and twice to make sure they have a very good reason to do it that way. So is there a very good reason to keep the attribute isInterface? -> Avoid using traits. Is is a sufficiently good reason? (I don't know because I did not use traits yet) nicolas _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
On 14 Feb 2011, at 13:13, Nicolas Anquetil wrote: > >>>> - 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. > > Traversing the inner types should not be too much work. This is a feature does is not very much used. Same thing for ParameterTypes. > > It does seem a pain to have to test all the time to distinguish innerClasses from ParameterTypes. > May be we can just make "parameters" an independent list to contain the parameterTypes? The problem with this is that it would also imply having an extra variable in ParameterType and that the container would no longer point to the ParameterizableClass which would mean that we would lose the scope definition. >> 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? > > My general opinion is that overriding implementation is fine, overriding intent is a bad idea. > Once one understood what a method is supposed to do or what an attribute means, one should not have to care what class one is looking at to know if this knowledge is still valid or not. > > So I would consider changing the meaning of "container" with a lot of care and currently I think it is probably a not-so-good idea. > > On the other way, the question is: what would be the meaning of "container" for ParameterType if we wanted to stick to the "normal" definition of container? > > And may be the answer is the ParameterizableClass? I am not too sure. > > Let's see it from another angle: Currently, the opposite of "container" is "types" defined as "Types contained (declared) in this entity" so can we say that a ParameterType is _declared_ in the ParameterizableClass? Yes, this is the current solution. I like this because the ParameterType is scoped by the ParameterizableClass. I think it's an Ok solution for now. > Maybe we should reconsider altogether the idea of defining ParameterType as a subclass of Type? Maybe we should set it apart just as AnnotationType? It must be a Type because it can be a declaredType for a method and an attribute. > [ Actually, this raises another unrelated question: Why is AnnotationType not a subclass > of Type? (I am looking at an image from 21/01/2011) ] Because AnnotationType cannot be used as a declaredType, thus the Type in FAMIXAnnotationType is not the same as Type from FAMIXType. >>> 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. > > Not sure how this work? > You mean for the use of a ParameterizableType, you define a new ParameterizedType that links back to its ParameterizableType and defines the ParameterType-s it uses? Yes. Plus, it has arguments that point to actual Types. > And what is the container of ParameterizedType? And its superclass? At the moment, both the container of a ParameterizedType and the superclass are nil. Perhaps we could have the container point to the method or the class in which it is defined? Also, > This is an idea I had too, but somehow I found that _declaring_ a new type when you want only to _use_ an existing type (and give it some parameters) was a bit outstretched, so I rather came with the new associations. > I was not sure which solution is the less worse (less worst?!? less bad?!?). I am still not sure. The thing is that it must be a Type because the a declaredType refers to it :) > >>> 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? > > Again, we can go back to the bases: I teach to my student that when they implement a "type" attribute to avoid defining sub-classes they should think really hard and twice to make sure they have a very good reason to do it that way. > So is there a very good reason to keep the attribute isInterface? > -> Avoid using traits. > Is is a sufficiently good reason? (I don't know because I did not use traits yet) We do not have to keep the isInterface attribute. I was just pointing out to the current state of affairs. The problem is that we have to model a 2x2 matrix of concepts: - class vs. interface - regular vs. parameterizable Traits would work just fine. I was actually asking why would we not do that :) Cheers, Doru > nicolas > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |