On Sat, Jan 27, 2018 at 12:00 AM, Ed Merks <ed.me...@gmail.com> 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. [image: Inline image 1] > > > On 26.01.2018 16:44, Leo Ufimtsev wrote: > > > > On Fri, Jan 26, 2018 at 3:33 AM, Ed Merks <ed.me...@gmail.com> 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 listcross-project-issues-...@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, >> visithttps://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 listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://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
