[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [xtext-dev] How to deal with copying / cloning existing functionality of Eclipse features
|
+1 for way 5)
Still 1) might be a viable choice in some scenarios, especially since
we're going to separate between UI-core and the default
implementations of different services, it would be ok, if one of those
services uses internal API from bundle X. But then it must be
explicitly declared through the MANIFEST that it depends on a specific
version of bundle X.
Note that there are also sometimes things which are entirely internal,
and cannot just be copied (because it's the whole thing, e.g. PDE).
Sven
On Sep 3, 2008, at 1:32 PM, Peter Friese wrote:
Hi,
when implementing some Xtext UI features and looking at code checked
in by some of you, I got the impression that there is quite a lot of
functionality in Eclipse that we would like to use, but can't
because it is internal.
I'd like to discuss this issue with you to find a reasonable way to
deal with this situation. Here are my thoughts:
1) Use internal code and ignore all warnings the compiler spits at us.
(-) Probably not a good solution, as it is likely to break in future
versions of Eclipse
2) Copy and paste existing internal code.
(-) Leads to code duplication.
(+) Code has already been tested.
(+) Achieve quick results: just copy'n'paste and you're (almost) done.
(-) If the original code gets updated / improved, we won't notice
this.
3) Write from scratch.
(-) Time-intensive
(-) Still produces duplicate code
(-) Code will contain more bugs that copied code (which already has
undergone some testing)
4) Request that internal code is made API (and moved up to a more
central location)
(+) No code duplication
(-) Need to persuade Eclipse developers to refactor code. In most
cases, two disparate Eclipse teams will be involved, so we'll need
to persuade two teams.
I'd like to propose a combination of (2) and (4):
5) Copy existing code, add a FIXME or REFACTORME marker and request
existing code be made public API
(+) immediate copy'n'paste re-use of existing code: quite productive
(+) we might be able to use API if the existing code is made API
(+) we won't forget about the origin of the code since we have added
a REFACTORME marker stating the origin of the code
I am interested in your opinions. Should there be anything I forgot
to think about, please complement.
Peter
_______________________________________________
xtext-dev mailing list
xtext-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/xtext-dev
