Mamy konstruktor public <R extends Number> Record(R param1, R param2).
Nie wiem czy istnieje jakakolwiek szansa, żeby w oparciu o type-bounds zaimplementować match. Chyba takie "super-elastic" metody będą po prostu bezużyteczne w przypadku reflective IClass. Normalnie to dużo prostsze przypadki nie przechodzą, więc płaczu nie ma.
net.ranides.assira.reflection.impl.RConstructorTest#testMatchGeneric
Mamy konstruktor `public <R extends Number> Record(R param1, R param2)`.
Nie wiem czy istnieje jakakolwiek szansa, żeby w oparciu o type-bounds zaimplementować `match`. Chyba takie "super-elastic" metody będą po prostu bezużyteczne w przypadku reflective IClass. Normalnie to dużo prostsze przypadki nie przechodzą, więc płaczu nie ma.
We match correct RWClass. We should NOT accept Integer constructors if we don't know the R. Even if R extends Number, it can be anything (for example R=Float!)
If we want to check if match generics works correctly for R extends Number, then we should search for a method with return type of R. We can check that.
Although it is not very useful, because java doesn't allow override return type, so filtering on return type is relatively pointless if we match by name.
To be precise: it works correctly!
We match correct RWClass. We should NOT accept Integer constructors if we don't know the R. Even if R extends Number, it can be anything (for example R=Float!)
If we want to check if match generics works correctly for R extends Number, then we should search for a method with return type of R. We can check that.
Although it is not very useful, because java doesn't allow override return type, so filtering on return type is relatively pointless if we match by name.
We must be even more precise. It is not like that. We don't match for class parameter extending Number, but "free form" method param R. This method WILL match Integer, Float and other Double, because correct method will be "generated on the fly".
We need to think about semantic here. Current behavior is formally correct. Practically "free form method param" with extends should have "swapped" upper and lower bound.
We must be even more precise. It is not like that. We don't match for class parameter extending Number, but "free form" method param R. This method WILL match Integer, Float and other Double, because correct method will be "generated on the fly".
We need to think about semantic here. Current behavior is formally correct. Practically "free form method param" with `extends` should have "swapped" upper and lower bound.
Don't use RFClass at all. Define correct specialization RMClass.
RMClass will work in "almost identical way" as RFClass.
Only difference is to swap upper and lower bound for RWClass if:
itype is RWClass (obviously)
generic type of RWClass is because of method parameter, not because of class
Solution is:
Don't use RFClass at all. Define correct specialization RMClass.
RMClass will work in "almost identical way" as RFClass.
Only difference is to swap upper and lower bound for RWClass if:
- itype is RWClass (obviously)
- generic type of RWClass is because of method parameter, not because of class
OK. We solved this in much less overdesigned way. Inside RArgument we just pass data into FClass factory. Factory decides if we should swap bounds inside constructed RWClass.
We still use ordinary RFClass as a wrapper for a pair {type, annotated type}
OK. We solved this in much less overdesigned way. Inside RArgument we just pass data into FClass factory. Factory decides if we should swap bounds inside constructed RWClass.
We still use ordinary RFClass as a wrapper for a pair `{type, annotated type}`
ranides hivatkozott erre a hibajegyre egy commit-ban ekkor: 3 éve
net.ranides.assira.reflection.impl.RConstructorTest#testMatchGeneric
Mamy konstruktor
public <R extends Number> Record(R param1, R param2).Nie wiem czy istnieje jakakolwiek szansa, żeby w oparciu o type-bounds zaimplementować
match. Chyba takie "super-elastic" metody będą po prostu bezużyteczne w przypadku reflective IClass. Normalnie to dużo prostsze przypadki nie przechodzą, więc płaczu nie ma.To be precise: it works correctly!
We match correct RWClass. We should NOT accept Integer constructors if we don't know the R. Even if R extends Number, it can be anything (for example R=Float!)
If we want to check if match generics works correctly for R extends Number, then we should search for a method with return type of R. We can check that.
Although it is not very useful, because java doesn't allow override return type, so filtering on return type is relatively pointless if we match by name.
We must be even more precise. It is not like that. We don't match for class parameter extending Number, but "free form" method param R. This method WILL match Integer, Float and other Double, because correct method will be "generated on the fly".
We need to think about semantic here. Current behavior is formally correct. Practically "free form method param" with
extendsshould have "swapped" upper and lower bound.Solution is:
Don't use RFClass at all. Define correct specialization RMClass.
RMClass will work in "almost identical way" as RFClass.
Only difference is to swap upper and lower bound for RWClass if:
OK. We solved this in much less overdesigned way. Inside RArgument we just pass data into FClass factory. Factory decides if we should swap bounds inside constructed RWClass.
We still use ordinary RFClass as a wrapper for a pair
{type, annotated type}