Comment #3 on issue 495 by andreho...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

OK! Thanks for the suggestion. Indeed I implemented creating a instanceVariable and I committed some minutes ago, before see this email :). But no problem, I will follow the suggestion.

Updates: Status: Started

Comment #5 on issue 495 by tudor.gi...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

Good work.

In the meantime I payed a bit more thought to this. Now, we have the extensions in three places. I think it would be cleaner to introduce two new entities: - FAMIXParameterizedClass as a subclass of FAMIXClass - for the definition of a generic class - FAMIXSpecificParameterizedType as an instance of FAMIXType - for the actual specific types specified as types of arguments

What do you think?

Comment #7 on issue 495 by tudor.gi...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

Indeed, I meant "FAMIXSpecificParameterizedType as a subclass of FAMIXType".

I also thought of FAMIXParameterizedType, but then it would be quite confusing to distinguish between this and FAMIXParameterizedClass. So, even if the name is longer and maybe clumsier, it would be worth it.

Here are other options: - FAMIXGenericClass / FAMIXParameterizableClass - FAMIXParameterizedType

Comment #9 on issue 495 by andreho...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

Yes. First of all I need to change (a lot :), I guess) VerveineJ to export these information, and then, change the Moose meta-model.

BTW, I have some questions. In the code below:

public class Class1<A,B,C> {

public Map<String,String> attribute1; public String attribute2;

public Map<String,String> method1(Map<String,String> parameter1) { Collection<String> localVariable1; ... } ... }

"Class1" is a FAMIXParameterizedClass with parameterTypes property A, B and C.

The total of FAMIXSpecificParameterizedType is 7 (one for each argument, as you said "for the actual specific types specified as types of arguments")?

"attribute1" contains two FAMIXSpecificParameterizedType stored in its (FAMIXStructuralEntity) declaredArgumentTypes property (which should be a <derived> property, the same to others declaredArgumentTypes properties). That's it?

So, which should be the fully qualified name of these FAMIXSpecificParameterizedType? I ask this because, for example, they are not the same String type of "attribute2" (which is a "normal" FAMIXType).

Moreover, which new properties will FAMIXSpecificParameterizedType contains? I see two: - Type: link FAMIXSpecificParameterizedType to its "real" type (the FAMIXType String, in the example) - Position: its position in the list of argument. What do you think?

Comment #11 on issue 495 by andreho...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

OK. Now it is cleaner. I was thinking in a different way. If I have more questions I return. Thanks!

Updates: Status: Started

Comment #13 on issue 495 by tudor.gi...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

It's not quite correct because the argumentTypes are not types, they are just symbols :). I am reviewing this right now. Until then, I am reopening the issue.

Updates: Status: Fixed

Comment #15 on issue 495 by tudor.gi...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

They were types :), but it is fixed now.

Updates: Status: Started

Comment #17 on issue 495 by tudor.gi...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

So, now we have ParameterizableClass having parameters as a collection of strings. The problem is that in this way we cannot model the below case.

First, T should actually be some sort of a local type that can be used as declaredType.

Second, T should also be allowed to inherit.

What a mess. Any ideas of how to model that?

----EXAMPLE----

interface MinMax<T extends Comparable<T>> { T min(); T max(); }

class MyClass<T extends Comparable<T>> implements MinMax<T> { T[] vals;

MyClass(T[] o) { vals = o; }

public T min() { T v = vals[0]; for(int i=1; i < vals.length; i++) if(vals[i].compareTo(v) < 0) v = vals[i];

return v; }

public T max() { T v = vals[0];

for(int i=1; i < vals.length; i++) if(vals[i].compareTo(v) > 0) v = vals[i];

return v; } }

public class GenIFDemo { public static void main(String args[]) { Integer inums[] = {3, 6, 2, 8, 6 }; Character chs[] = {'b', 'r', 'p', 'w' };

MyClass<Integer> iob = new MyClass<Integer>(inums); MyClass<Character> cob = new MyClass<Character>(chs);

System.out.println("Max value in inums: " + iob.max()); System.out.println("Min value in inums: " + iob.min());

System.out.println("Max value in chs: " + cob.max()); System.out.println("Min value in chs: " + cob.min()); } }

I haven't closely followed the topic, but infusion does not provide parameter information if I remember correctly. Does Verveine completely replace infusion?

The moose book does nor mention verveine: http://www.themoosebook.org/book/externals/import-export/java

Cheers, Alexandre

Le 13 févr. 2011 à 14:16, moose-technology@googlecode.com a écrit :

Comment #18 on issue 495 by tudor.gi...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

Now I introduced ParameterType that has as container the ParameterizableClass.

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates: Status: Fixed

Comment #19 on issue 495 by tudor.gi...@gmail.com: Parametrized Types - Generics http://code.google.com/p/moose-technology/issues/detail?id=495

The current solution is reasonable. I mark it as fixed.