Greetings Stephan,
This is actually a very interesting example. Well, interesting to me anyway (which I guess explains the length of this post).
I can repeat what you are showing, but its not that 9.2.2 is incorrect...its just that 10.0.0 has new type reconstruction capability that allows it to know exactly the types involved.
When I do the following in 9.2.2
Float emax = Float em<code completion request>
what I see are a listing of entries...some with precedence arrows...Some without.
I see 2 entries for emax. Look near the bottom and you will see the one without the precedence arrow. That is the one that applies to the Float receiver. The other one applies to the (Float emax = Float) expression receiver.
When I do this in 10.0.0, I only see a single #emax entry for the Float receiver.
Why?
The answer starts all the way back at the first instance of 'Float emax'.
In 9.2.2, the type of the expression 'Float emax' is unresolved...so its going to show you all possible suggestions.
The reason the type is unresolved is that there isn't any logic that would tell it how to look inside the method Float>>emax and then attempt to figure out what the return type is.
In 10.0.0...there is. Its using bytecode analysis.
10.0.0 has 2 additional type reconstruction/analysis features. Bytecode analysis and Type annotations.
Bytecode Analysis
If you look inside Float>>emax you see a very simple ^308.
Therefore, the return type of Float>>emax is <SmallInteger>.
This seems like a pretty easy method to type using the existing machinery which uses a combination of token and parse-tree analysis.
However, these types of analysis require source code. It turns out that its not a great idea to have the tooling go around loading up CompiledMethod source from ENVY in a recursive manner as it tries to type expressions.
Therefore, if we branch out and start peering inside compiled methods...its better to analyze the already loaded bytecodes rather than make ENVY requests for source code.
As of 10.0.0, we introduced a bytecode analyzer that can identify patterns of bytecodes and, if required, type analyze arguments encoded in the bytecodes or as literals which the bytecode indirectly refer to.
So in 10.0.0, if you request code completion for the 'Float emax' expression, you will see that it is resolved as the type <SmallInteger>.
Since it knows 'Float emax' is of type <SmallInteger>, it then goes on to type the expression 'Float emax = Float'.
And it knows this means it must bytecode analyze the method SmallInteger>>=.
By doing so it sees a primitive call to <VMprSmallIntegerEqual> inside that method which it knows is of return type <Boolean>.
Now back to our original example
Float emax = Float <code completion request>.
Instead of resolving it to the aggregate type <Unresolved, Float> that was in 9.2.2
10.0.0 considers that expression to be the aggregate type <Boolean, Float>.
And emax is only implemented (normally) in Float and not Boolean...so the choice is obvious because there is only one.
The bottom line is that typing information flows through the expressions in a method. Typing things successfully as early as possible
can give great information later that almost seems like magic (as some have put it to me). Well its not magic...its just a lot of analysis that
is all connected. Its great for code completion but its also great for analyzers that are looking to see if the types are still flowing feasibly as
you refactor your methods. I've been saved many times earlier by such refactorings that would have gone out the door as DoNotUnderstand errors.
Most I might have caught thought SUnit tests...but its questionable for some and the goal is always to fail early.
Type Annotations
EsAsynchronousSupport is a new application that has type annotations for EsFuture and EsPromise.
Type Annotations describe return types and argument types. This is connected to both code completion and type analysis
and will help the type resolver out if it knows which method(s) are involved because it knows how to peer
inside and extract that type information.
Hope that this explanation helps.
- Seth