Am 14.07.2018 um 23:14 schrieb Tim Boudreau:
On Sat, Jul 14, 2018 at 6:23 AM Neil C Smith <[email protected]> wrote:
On Sat, 14 Jul 2018 at 05:41, Tim Boudreau <[email protected]> wrote:
I was there when friend APIs were being invented. The *entire* purpose
was
for a developer to evolve an API,
Well, fair enough, can't argue with that (although I'd argue there are
uses now that aren't for that purpose). Still seems the wrong way
around to me in comparison to other things I've worked with.
IMO, there *is no such thing as a "true friend" API.* If you don't want
to
publish an API, put all of your code in one module - the compatibility
contract is between that module and itself. If module X depends on
module
Y, and nothing else may depend on Y, and X cannot function without Y,
then
you have *a single logical module.* You might think it looks nicer
carved
up into two pieces, but at that point you're doing code feng shui, not
engineering.
There are other reasons for using more than one module where you
*never* intend to create a public API, but need other aspects of the
module system - optionally loaded parts, OS-specific parts, etc. So I
*am* thinking of a small number of things that are logically a unit.
True that things like OS-specific pieces are a special case. Optional
seems iffy (unless it's huge, just bundle it but don't load it if you don't
need it).
But I think there's also a bit of social nudging any infrastructure around
this inevitably does - and a solution where creating a public, maintained
API with a commitment to backward compatibility is the path of least
resistance is going to have far more benefits for the project as a whole
than one where creating permanent friend APIs is the path of least
resistance, and that's what the existing way of doing things has gotten us.
If you have "non-stable dependencies", eventually that is all that will
exist. Nobody would prefer to keep compatibility if they don't have to.
Well, that's a pessimistic viewpoint! ;-)
19 years working on or involved in a project will do that :-)
But seriously, if you have a shifting team of developers over a period of
years, the best guarantee that the things you want to happen on an ongoing
basis are remembered is if there is automation and infrastructure that
makes them a natural part of doing work. Otherwise you're relying on
institutional knowledge and someone having the time and concern to do it.
I've seen "please make my module a friend of X" bugs languish for 6-9
months simply because it wasn't someone's priority, and they were working
for someone who didn't see it as a priority either. If it's "hey we better
stabilize this or we've got to live with it as-is", that makes it a
priority, like it or not.
But I agree with you that
time-limiting instability is probably a good idea. And if optionally
installed modules can only be installed against a single release
(major/minor not point) of the IDE (and perhaps show a big warning
dialog to that fact) I think you'd see things pushed to become stable.
You can. If you're writing an IDE module, your users can't. They just
upgrade the IDE and find something doesn't work anymore, say "this sucks"
and go download Eclipse.
I'd argue that the friend system has made that problem worse not
better. Assuming in-development API's don't change via automatic
updates as opposed to manual upgrade, then I don't see the issue here.
With the friend API you either don't have the module in the first
place, or a module that's had to hack its way into working in such a
way that it's more prone to breakage?!
Agree that it doesn't help much - heck, just recently I was playing with
Rust and found someone's Rust plugin on Github, which uses a ton of friend
and implementation dependencies that are broken, and rather than dig into
it I gave up.
A process that time-limits "unstable" APIs would fix that.
-Tim
While I appriciate the idea of automatically propagating API state from
instable/friend to stable after some time, there may also be less APIs
as a result. So probably there should be some group of people, e.g. QA
team, deciding on where APIs should be defined. Then an API should be
defined and reviewed, say version 0.1 (to express it's still early alpha
stage).
This API should then be implemented and further discussed (You'll
probably see during implementation what can be handled better some other
way, or simply where the specification is incomplete, erroneous or just
unspecified).
Another issue is still module splitting - bigger feature implementations
are often splitted into several modules, which need the ability to
privately access each other. This also results in some mismatch:
Sometimes it would be nice to be able to expose some APIs as
friend-only, while others are interesting for public usage. Currently,
only either export is possible. While one can split the exporting module
once more, this is probably not always convenient - probably this should
be fixed. Also, such module-clsuters should probably be friends by
convention, i.e. there should probably be some concept similar to
"NetBeans Suite" projects (by sharing some token, residing together in a
"sub-cluster" or sth. similar).
Only in this context, IMHO it could be a good idea, to automatically
propagate status.
Therefore I'd prefer to:
- set up a community page for API request. This page may just explain,
what to do, e.g. create a Jira issue, which parameters tu use (should be
task or wish or ..., keywords, etc.);
- set up a responsible QA team;
- discuss the API on the dev list with interested members.
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
