Hello Ed,
On Wed, Jan 24, 2018 at 7:27 AM, Ed Merks <ed.me...@gmail.com> wrote:
> I'm a more than little annoyed to see that this method
>
> org.eclipse.jface.internal.text.html.HTMLPrinter.insertPageProlog(StringBuffer,
> int, RGB, RGB, String)
>
> I understand your frustration, we sometimes have to deal with similar
problems.
E.g when Gtk makes changes to their methods, it breaks SWT and causes
glitches in Eclipse.
But:
As the package suggests, it's an *internal* method: org.eclipse.jface.
*internal*.text.html.
'Internal' means it's not suppose to be used by public.
If you wish to use internal api because it's useful to you, then you should
first put in effort to make
the api public and *only then* use it. Not use it and then complain about
it's removal.
Because you chose to use internal api, and your suggestion to revert the
code removal, you are slowing down platform
development and by extension slowing down the whole Eclipse development
process.
It's very important for us to stay agile and move quickly, this involves
being able to refactor old code, remove redundant code etc..
As case in point, in Fedora, "yum" got dropped and replaced with 'dnf'
package manager
because "yum" had too much internal api being used by external users and
they couldn't refactor/stay agile.
My experience with HTMLPrinter is that it took me longer than necessary to
fix some color related issues
in platform because HTML printer was such a mess of multiple redundant
methods.
I'm actually very glad those methods were removed and I think they should
stay removed.
This is nothing personal. If we move too slowly, eclipse will die and we
will all loose :-(.
Moving forward, I suggest we help each other move fast and keep things
going quickly.
This involves not using internal api and try to make sure platform
development is fast and effective.
Thanks
has gone from deprecated to deleted in less than a 5 week period:
>
> https://github.com/eclipse/eclipse.platform.text/commits/mas
> ter/org.eclipse.jface.text/src/org/eclipse/jface/internal/
> text/html/HTMLPrinter.java
>
> JDT, EMF, Xtext, and Oomph all use this method.
>
> I really don't care to hear the arguments about it being internal because:
>
>1. I don't see that JDT ought to have exclusive special privileges to
>use internal things.
>2. I don't see any reason why it should be internal.
>3. And any client wanting to implement hovers that work like the ones
>for JDT, will have the same needs as JDT and will solve the problem the
>same way.
>
> I'd like to avoid dwelling on the fact that this is simply a pointless
> change, but I can't help it. Surely one wouldn't change this simply to
> improve performance in code that has no relevant performance impact! It
> seems to me at best a misguided effort that would be better spent on real
> improvements.
>
> Please revert this change before M5.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=530240
>
> And in the future, please consider that any internal API that is used by
> any other project is going to cause problems for many projects just as it
> did for JDT:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=529118
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
--
Leo Ufimtsev, Software Engineer, Red Hat
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
