Re: [xtext-dev] How to deal with copying / cloning existing functionalit

["michael clay" <clay@xxxxxxxxxxxx>]

hi peter,

vote: +1 for 5

back from holidays since yesterday.. i think you are talking about the
classes (org.eclipse.xtext.ui.wizards.dialogfields) i've introduced
togehter with the 'Task marker' preference page enhancement..right?
Indeed i've avoided to reinvent existing components to take advantage
of already proofed source code and for reasons of increased
productivity. Since theses classes are included in a private (JDT)
bundle i have to copy them while keeping the existing license header
intact.

m.


On Wed, Sep 3, 2008 at 2:06 PM, Sven Efftinge <sven@xxxxxxxxxxx> wrote:
> +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
>
> _______________________________________________
> xtext-dev mailing list
> xtext-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/xtext-dev
>