Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] About the Bayesian network in Eclipse Code Recommenders

Hi Cheng,


could you please have a look at [1] and tell me if this *could* work in for argument completion? I haven’t made any computations or sanity checks yet. Just a sketch. The network file is available here [2]. If you *think* it covers all required data, I’ll start populating it with some data and tweak it towards a smaller memory consumption etc.

Cheers,
Marcel


On 09.08.2012, at 19:45, Marcel Bruch wrote:

Still thinking :)

Just two immediate follow-ups:

On 09.08.2012, at 19:36, Cheng Zhang wrote:

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?

No. It may be okay to have one “parameter-type-node” with all types you have observed that have been used as argument to this particular method:


name:parameter-type-node
state1:o.e.s.w.Button
state2:o.e.s.w.Label
state3:o.e.s.w.Composite
...

Method Nodes can than be shared over all types. You may even not need to fully qualify them with type name and method name and signature - a short name could do the trick. In that case, however, you need to introduce another latent node that creates the mapping between the parameter-type-node and the parameter-observed-calls node. But that seems reasonable to me.


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).

I see :)

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.

We may have something in place for this. But let’s focus on the other model issues first :)

Any thoughts or suggestions?


I think, I’ll set up a VM tomorrow afternoon to draft a few network structures with Genie.

Best,
Marcel


Thanks,
Cheng 
 

BTW: Michael, are you listening? ;)

Thanks,
Marcel

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Eclipse Code Recommenders:
 w eclipse.org/recommenders
 w about.me/mbruch


-- 
Eclipse Code Recommenders:
 w eclipse.org/recommenders
 w about.me/mbruch


Back to the top