HTML and Palette have been mentioned as examples here only. When I'm
ready to change sth., I'll provide a pull request together with starting
a separate discussion.
However, I remember being stopped from Friend APIs some long time ago,
so IMHO this should be discussed.
I understand, there're two different points of view:
1. API user's view: Give me as many APIs as possible, so I can do almost
everything with the IDE.
2. IDE developers view: Provide as few as possible, only absolutely
necessary, so IDE changes can be freely developed without impact to API
users.
These two views have to be considered for API state, and I'd be happy,
if this discussion would lead to a better understanding of these and
probably some rules, how to handle these. Hopefully this will lead to
some rules for the Apache NetBeans project, how API state could be
handled in a better and especially more transparent process.
Regards
Peter
Am 13.07.2018 um 08:33 schrieb Geertjan Wielenga:
Maybe a starting point could be for you to provide a pull request with the
changes you'd like and then we can discuss that and agree together whether
or not those changes make sense.
Gj
On Fri, Jul 13, 2018 at 8:27 AM, Peter Nabbefeld <[email protected]>
wrote:
If this process (hardening the API and releasing it as public) would have
been followed, it would be great. Unfortunately, it seems there're a bunch
of useful APIs now which are not even part of the javadoc at
bits.netbeans.org (and therefore mostly unknown) and seem to never be
released.
Some other APIs (like Palette API) seem to have extensions in many parts
(= collections of modules building a functional part, like HTML support) of
NetBeans, which could probably be made more general and then moved into the
"Main API" (Palette, in this case), so everybody could use those. E.g. html
module seems to have the ability to activate parts of different HTML APIs
via layer, and some interface is there defined (but not yet used) to do
this programmatically (probably using annotations). IMHO, this could be
useful for other parts, too.
So, while NetBeans moves to Apache, I'd like to further discuss the
process of extending and hardening APIs.
Regards
Peter
Am 13.07.2018 um 04:28 schrieb Tim Boudreau:
The original idea of friend apis was to allow development of an api with
the understanding that nobody gets things perfect the first time, so
clients v could be developed but at the risk of dealing with breakage.
The point was for the api to be in friend mode until it matures, at which
point it becomes official compatible api. That's the part that never
happened - no mechanism pushing moving apis out of friend mode.
I'd suggest a rule that that happens automatically if a friend api has
been
around for more than 2-3 releases. Enforcement of that could probably be
automated with a bit of auto bug filing cleverness.
-Tim
On Thu, Jul 12, 2018 at 7:11 PM 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
--
http://timboudreau.com
---------------------------------------------------------------------
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
