search

JetBrains / ruby-type-inference

Dynamic definitions and types provider for ruby static analysis
Apache License 2.0
137 stars 7 forks source link

bobko/parameter-types #26

Closed nikitabobko closed 5 years ago

nikitabobko commented 6 years ago

Primarily added new sql CallInfoTable where store all call infos. And provide types for parameters using data from this table.

nikitabobko commented 6 years ago

Answering questions: Question:

What is the real difference between CallInfoTable and existing Contract collection?

Answer: If you mean SignatureContract than for me it looks too complex. They stores such strange automaton. I even still don't understand purposes of such automatons. For predicting types?

Do you have any threshold on the number of collected types for a parameter?

Answer: No I don't have any threshold on the number of collected types for a parameter. I store them fairly. But RTypeUtil.union won't allow me to show more than 8 types. Should I do any restrictions on number of collected types for a parameter?

valich commented 6 years ago

I even still don't understand purposes of such automatons. For predicting types?

They store automatons describing all possible input-output combinations, as well as relations between different input types. For example, if there are two calls (Int, Int) -> Int and (String, String) -> String, the first parameter will be "Int or String", the second will be "same as 1st", the return type is "same as 1st", so possible types of parameters can be derived from it.

Pros of such structure: (1) there is a relation between data on different tuple positions (for example you could suggest user that the second parameter should be String if they inserted the first parameter and it is String); (2) It might take less space in some cases (though probably will take more in some others)

Cons: (1) It requires CPU time and more complex algorithm to build such automaton from input tuples (2) it requires some CPU time for getting the "answer", though it's quite straightforward

Should I do any restrictions on number of collected types for a parameter?

If there's a library method which receives any type and is heavily used, you'll store hundreds+ types internally, but will always return REmptyType to clients because you can't union more than 8.