Leo,
Arguably HTMLPrinter is not really a good API so to make it API, it
should be turned into a good API first. But that's apparently difficult
and hasn't been done despite requests for it.
SWT is indeed a shining example. Steve Northover is a brilliant
designer. I've never seen any need to dive into internals, and didn't
even know they existed until I looked just now!
I also feel compelled to say that the community as a whole appreciates
the efforts (and your personal efforts) that go into maintaining and
enhancing SWT's GTK support. It certainly entitles you to have opinions
about which development paths work well and which development paths seem
less than ideal. Thanks for sharing your contributions and opinions
with the community.
Of course operating systems don't run as a JVM that allows reflection to
subvert all protection but in any case that too is a great example of
how things ought to work.
Cheers,
Ed
On 26.01.2018 16:44, Leo Ufimtsev wrote:
On Fri, Jan 26, 2018 at 3:33 AM, Ed Merks <[email protected]
<mailto:[email protected]>> wrote:
Leo,
I have read the whole thread.
Comments below.
On 25.01.2018 17:44, Leo Ufimtsev wrote:
I haven't read the whole thread.
But I think it's fairly common sense that one should not use
internal api by an external project. It's just one of life's axioms.
It's definitely best avoided, when possible, but that's the
caveat. When it's not possible to implement JDT without using UI
internals and it's not possible to implement PDE without p2
internals then axiomatically it follows that others wanting to
implement cool functionality like these projects do will find
themselves in the same boat.
From what I gather, HTMLPrinter is a convenience class "Provides a set
of convenience methods for creating HTML pages.".
To me this looks like something that should have first been made
public before referencing it.
Kinda following Linus's emails, changes in user apps shouldn't break
kernel and changes in kernel shouldn't break user apps.
It's like people who use reflection to get to private members of
a java class and deploy that code into production.
The Eclipse itself runtime does exactly that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209>
That's just a 'quick' workaround that generates unstable products.
Yes, it's less than ideal, with the added huge disadvantage that
you only see failures at runtime, so the tests better be good.
I really cannot see any way to justify using internal api for use
in a stable product beyond testing / development / exploration /
proof of concept.
Yet the platform project's own teams make a habit of this
practice. That too would appear to be unjustifiable.
And by extension, internal api should be subject to change and
removal at any given time without prior notice.
I understand that you primarily see this as black or white, but
thank goodness the JDT team doesn't take this attitude and sees
all the shades of gray between the extremes.
I can only suggest that you look carefully within your glass
house, making sure its furnishings set the highest standard with
regard to the fundamental principles according to which you expect
others to furnish their houses.
In SWT not even our JUnits reference our internal api.
Thanks.
--
Leo Ufimtsev, Software Engineer, Red Hat
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
--
Leo Ufimtsev, Software Engineer, Red Hat
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
