Effects of R#-Option "Show member signatures"

[Dennis Albrecht]

Hey guys,

I just tested what effects the R#-Option has and I wanted to collect my results here so that nothing gets lost (forgotten).

• enabling the option changes the visual part (as expected) but the model behaves similar, which means that both the CompletionEvent-Generator and the ProposalProvider still work like in the disabled case
• It seems, that EventGenerator and ProposalProvider always "select" the same signature to represent some proposal if the option is disabled (I tested with StringBuilder and the Append-Method and the dominant signature always was "Append(char, int)")
• if the option is enabled and the ProposalProvider recommends multiple signatures of one method, then they are all on top of the list with relevance and so on
• if the option is disabled and the ProposalProvider recommends the wrong signature of one method, then the method isn't recommended (or to be more precise: if every signature is recommended, the overall method will have a (from my point of view) randomly selected relevance from the list of relevances of the different signatures)
  
• (basic information) if the option is enabled and you complete on one signature, the only difference in the behaviour is that this signature is selected in the list of signatures that appears after the CodeCompletion closed (its the same signature-list that you see if the option is disabled and you navigate to the method in the CodeCompletion)
• if the option is enabled and you navigate through the CodeCompletion, the different selected signatures are logged, otherwise the dominant signature gets logged, hence, completing will either be logged as the dominant signature (in the disabled case) or as the actual selected signature (in the enabled case)
  

Greets Dennis

[Sven Amann]

In other words, the completion behaves differently, depending on the option, right?

* If “show member signatures” is disabled, we only ever see the “dominant” signature. We then only every recommend this signature.
* If “show member signatures” is enabled, we see all the available signatures separately. We then recommend specific signatures.

This poses the following problems:

* If the option is disabled, our learning is imprecise. If we recommend for someone with the option enabled, we may recommend the “wrong” signature, as we recommend the “dominant” one, not the specific one(s).
* If the option is enabled, our learning is precise w.r.t the signatures. If we recommend for someone with the option disabled, we may not recommend anything, because the specific signature may not be the “dominant” one and, therefore, invisible to us.

Proposal:

1) Since we cannot detect the specific signature in case the option is disabled, I’d say we should mark the information as “any signature”.
2) We should consider this abstraction in the learning.
3) When recommending, we should move the group proposal (option disabled) considering proposals for specific subsumed signatures.

What do you think?

Best,
Sven

> --
> You received this message because you are subscribed to the Google Groups "kave-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kave-dev+u...@googlegroups.com.
> To post to this group, send email to kave...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kave-dev/5927ab76-a11c-4eed-9eea-d90a09c6406d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Dennis Albrecht]

In other words, the completion behaves differently, depending on the option, right?

* If “show member signatures” is disabled, we only ever see the “dominant” signature. We then only every recommend this signature.
* If “show member signatures” is enabled, we see all the available signatures separately. We then recommend specific signatures.

That's right. 

This poses the following problems:

* If the option is disabled, our learning is imprecise. If we recommend for someone with the option enabled, we may recommend the “wrong” signature, as we recommend the “dominant” one, not the specific one(s).
* If the option is enabled, our learning is precise w.r.t the signatures. If we recommend for someone with the option disabled, we may not recommend anything, because the specific signature may not be the “dominant” one and, therefore, invisible to us.

 
I'm not sure about this because I'm not sure about how our learning process works. If we learn on the code-completion-events then you're right (except that I would add to the second one something like "we may recommend the method with the relevance of some arbitrary signature (with relatively low relevance)"). If we (mostly) learn on repositories we would only have the second problem.

Proposal:

1) Since we cannot detect the specific signature in case the option is disabled, I’d say we should mark the information as “any signature”.

Something like C#-understanding of Method-Groups would be a good idea. In case the option is disabled, convert a LookupItem in a MethodGroupProposal that contains the declaring type and the Methods name and a set of all possible MethodNames. In this case it would still be one proposal. (Just a idea)
 

2) We should consider this abstraction in the learning.

Depending on which data we learn on, we may have to find some solution. If we only learn on repositories we do not have to change anything (because in working code we can identify the exact signature).
 

3) When recommending, we should move the group proposal (option disabled) considering proposals for specific subsumed signatures.

 
Yes.

What do you think?

Best,
Sven

Greets Dennis

[Sven Amann]

On 13.10.2014, at 15:25, Dennis Albrecht <dennis.alb...@gmail.com> wrote:

>> In other words, the completion behaves differently, depending on the option, right?
>>
>> * If “show member signatures” is disabled, we only ever see the “dominant” signature. We then only every recommend this signature.
>> * If “show member signatures” is enabled, we see all the available signatures separately. We then recommend specific signatures.
>
> That's right.
>
>> This poses the following problems:
>>
>> * If the option is disabled, our learning is imprecise. If we recommend for someone with the option enabled, we may recommend the “wrong” signature, as we recommend the “dominant” one, not the specific one(s).
>> * If the option is enabled, our learning is precise w.r.t the signatures. If we recommend for someone with the option disabled, we may not recommend anything, because the specific signature may not be the “dominant” one and, therefore, invisible to us.
>
> I'm not sure about this because I'm not sure about how our learning process works. If we learn on the code-completion-events then you're right (except that I would add to the second one something like "we may recommend the method with the relevance of some arbitrary signature (with relatively low relevance)"). If we (mostly) learn on repositories we would only have the second problem.

Ok, you’re right.

>> Proposal:
>>
>> 1) Since we cannot detect the specific signature in case the option is disabled, I’d say we should mark the information as “any signature”.
>
> Something like C#-understanding of Method-Groups would be a good idea. In case the option is disabled, convert a LookupItem in a MethodGroupProposal that contains the declaring type and the Methods name and a set of all possible MethodNames. In this case it would still be one proposal. (Just a idea)

I don’t think we get anything from remembering all candidates, because we cannot decide which one(s) are relevant and this means remembering all is just as good as remembering that we don’t know the precise signature. But yes, I think we should somehow “flag” the proposal(s).

>> 2) We should consider this abstraction in the learning.
>
> Depending on which data we learn on, we may have to find some solution. If we only learn on repositories we do not have to change anything (because in working code we can identify the exact signature).
>
>> 3) When recommending, we should move the group proposal (option disabled) considering proposals for specific subsumed signatures.
>
> Yes.

Best,
Sven

[Dennis Albrecht]

Am Montag, 13. Oktober 2014 16:14:45 UTC+2 schrieb Sven Amann:

>> Proposal:
>>
>> 1) Since we cannot detect the specific signature in case the option is disabled, I’d say we should mark the information as “any signature”.
>
> Something like C#-understanding of Method-Groups would be a good idea. In case the option is disabled, convert a LookupItem in a MethodGroupProposal that contains the declaring type and the Methods name and a set of all possible MethodNames. In this case it would still be one proposal. (Just a idea)

I don’t think we get anything from remembering all candidates, because we cannot decide which one(s) are relevant and this means remembering all is just as good as remembering that we don’t know the precise signature. But yes, I think we should somehow “flag” the proposal(s).

 
Just because I'm still remembering why I proposed the method-group-idea: For the completion-events and the learning some "any signature"-flag would be sufficient but the ProposalProvider needs all exact signatures to find matches with the recommender-network. The information "Some Method like 'DeclaringType.MethodName' with any concrete signature" is not enough because the network only offers complete MethodNames.

Greets Dennis

[Sven Amann]

The ProposaProvider doesn’t need all the signatures. The concrete signatures are known to the network. Therefore, I can get all concrete signatures that match an abstract pattern from the network and then query for those. No need to duplicate information.

Best,
Sven