[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ease-dev] GSoC code competion commits
|
Hi Martin,
your latest commits brought us in a delicate situation.
You commited 14 topics, all depending on each other. Some of them will
need some adaptions/discussions. But if 1 patch set is declined, the
next elements in the chain cannot be merged anymore. So you have to step
back to the first declined topic and start from there to rework the topic.
Also having 14 commits with the exact same commit message is not exactly
what I was expecting. As discussed offline: smaller commits do not only
help to avoid the 1000 LOC rule. They also help to cluster topics and
make reviews easier.
One major concern of mine are those changes to the IModuleWrapper
interface. While you adapted the one for Rhino, your changes will break
compatibility for our external interpreters for Python, Groovy and Ruby.
IModuleWrappers are there to generate code chunks, so I think they might
be useful when you want to convert a java call to a scripted command,
but currently I see no point in changing them for code completion
proposals. If you think these changes are needed, we should discuss it
on the list.
A second topic is that the script shell should not need knowledge of
several code completion implementations. Your adapter should take care
of chosing the correct completion providers depending whether we are
working on a live interpreter or within an editor. So one option would
be to set a script interpreter instance and/or a script type in the
adapter. Then the adapter can chose matching completion providers by itself.
Completion providers generally should not be hard coded into the system.
We should use extension points to register them along with some metadata
(eg a language filter, whether they are applicable on a script
interpreter or also offline, ...). Then the adapter should load them
dynamically depending on the environment.
HTH
Christian
