Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] HTMLPrinter is Broken

On Sat, Jan 27, 2018 at 12:00 AM, Ed Merks <ed.merks@xxxxxxxxx> wrote:

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

Thank you.

Best regards from Canada.
Inline image 1

 


On 26.01.2018 16:44, Leo Ufimtsev wrote:


On Fri, Jan 26, 2018 at 3:33 AM, Ed Merks <ed.merks@xxxxxxxxx> 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
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
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


_______________________________________________
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


_______________________________________________
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

Back to the top