Open Nzsquall opened 8 years ago
Hello Eric,
As for the resolving method - there is a bug while determining type of getArrayList()[0]. Due to the bug type is determined to ArrayList
As for the math and boolean operators - it is not implemented yet. This will involve a lot of work for writing grammar and type derivation while usage. So I could not promise this feature next release..
I am planning to release in the beginning of July, but I will provide snapshot version with type derivation fixed here.
Thanks, Eugene
Hello Eric,
I did couple of updates to type resolver system related to resolving generics type, better handling arrays and brackets (math and boolean operations are not included yet), could you please test if IdeaConcordionSupport-0.9-SNAPSHOT.zip works fine ? Please let me know if current version seems to be slower then before.
Thanks, Eugene
Hi Eugene,
Thanks for the quick fix, working like a charm for that one now.
I will let you know if I observe any slower performance.
Thanks Eric
Another small issue I notice as below.
In the fixture class I have this method fooBar() that returns a multi level HashMap.
The following expresssion in the spec are flagged as error by the IDE: c:assertTrue="fooBar().keyLevel1.keyLevel2.equals('some string')"
Where the value for this key keyLevel2 in the map returned are type String.
Not too worry about this one actually but I am wondering if this is something that can be fixed quickly?
I supposed you won't really know before run time what type of the value that map key corresponds to?
Thanks Eric
Hello,
I was unable to reproduce last issue.
Types are deducted from generics.
Thanks, Ievgen
There seems to be a problem that I can't jump to method declaration from the spec to its associated fixture classes, if the argument was made of math, or boolean operator.
For example in the fixture classes, I have a method signature as below: fooBar (String var1)
When I used this method from the spec, I use this: fooBar(#someVar + #anotherVar)
The plug in fails to associate this method with its fixture classes.
Another example is: fooBar (String var1, String var2)
I used this method from the spec as: fooBar (#someVar, getArrayList()[0])
Where getArrayList() is defined in the fixture classes and return type as ArrayList.
Is it possible to fix this in the next release version?
Thanks Eric