+1 Gj
On Sat, Jul 21, 2018 at 9:01 AM, Emilian Bold < [email protected]> wrote: > I think you are annoyed by friend APIs just because nobody cared through > time about those APIs to bring them to a public API. But that's just a sign > of no money / human resources poured into it, not a lack of automation or > other processes. > > If you somehow force people to reconsider friend APIs as they become > public in 2 releases then they will just stop using friend APIs and find > other creative ways via reflection, the global lookup, etc. So... you only > obfuscate the matter. > > Note that the Friend API is not only for NetBeans! You could also have > your own bunch of modules and defined friends among some of them, etc. I > know that some NetBeans friend APIs are quite juicy so I understand the > frustration but it's a frustration with the NetBeans codebase, not the > concept itself. > > --emi > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On 13 July 2018 2:11 AM, Peter Nabbefeld <[email protected]> wrote: > > > Hello all, > > > > I personally don't like "Friend" APIs, as really I like the idea of an > > > > open, extensible IDE. > > > > From my point of view, Friend APIs make it difficult or impossible to > > > > extend NetBeans for personal use: > > > > - You have to ask for being added to the friends list. This is > > > > especially a problem, if You want to implement some private-use > feature, > > > > e.g. for Your employer. > > > > - Alternatively You could depend on the implementation version; but I > > > > don't see how to do that, if You're using Maven. > > > > - Third possibility is just patching the modules to remove the friends > > > > and make the API public - very ugly, and You have to do it after > every > > > > update. > > > > OTOH, having a friends-only API leads to fewer dependencies on the > API, > > > > thus less impact from changes to the API, which makes work easier for > > > > the developers, of course. > > > > However, if an API isn't stable, yet, it could also just be flagged > as > > > > "Under Development", thus telling users of those, that it is subject > to > > > > change. Also, as it is possible to use default methods in interfaces > > > > from Java 8, it should be less of a problem to extend an existing > API. > > > > But You can use the API on Your own risk without any conflicts. > > > > An exception of course is having APIs only for modularity, if classes > > > > are spread over different modules and need an API to interact with > each > > > > other. In this case the API's purpose is not to integrate extensions, > > > > but to split responsibilities - in this case I fully agree these are > not > > > > for public use. > > > > I'd be interested in comments on this - so, what do You think? > > > > Kind regards > > > > Peter > > > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
