I looked a while on your example and network. I think I got most of it but I’ve a few questions regarding your example:
the red part is “to be completed” right? See below:
panel.setAttrib(<ctrl+space>); // should be completed to b.getAttrib()?
Yes, exactly, a successful recommendation will recommend the _expression_ "b.getAttrib()".
How do you map this in your network - or do you have different networks for different argument types?
panel.setAttrib(b.<ctrl+space>); // should be completed to getAttrib()?
In our current design, I am afraid we have mingled different argument types and represent them using
different nodes in the same network (rather than different networks).
So, one of your suggestion is that we can try to use different networks for different argument types. Right?
Btw, for the particular case (the second one), our current solution does not recommend the partial _expression_, i.e. getAttrib().
It may seem somewhat weird. The reason is that we deem such a use case should be supported by method call recommenders (e.g. your FSE work).
To keep our solution simple, we just took the same strategy for qualified names/field accesses, that is,
recommending the whole expressions, instead of a partial ones, as arguments.
Probably, recommending method calls that are used as arguments is different from recommending method calls in general,
since the return types are specified and some argument-specific contexts may take effect.
Any thoughts or suggestions?
Thanks,
Cheng
BTW: Michael, are you listening? ;)
Thanks,
Marcel
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
