In my opinion, we Need more and more public apis, to extend everything in NetBeans. Here are some more examples: It is not possible to extend all other Editors, except from Java. The most usable public API is for the Java Editor. You can extend add hints for example, but only for the Java Editor.
You can’t add hints for PHP, C/C++, HTML, XML, JS, CSS, LESS, SCSS, etc. We can’t create Plugins for mixing languages together like embedding languages of using SQL inside any language, where it is needed etc. Because we can’t get Access to the Tokens of any other languages except from Java. No SQLTokens, no JSTokens, no HTMLTokens, etc. So public apis and stable/unstable flags are a must have, to extend the DIE with 3rd-party-plugins IMHO. Cheers Chris Von: Tim Boudreau Gesendet: Samstag, 14. Juli 2018 23:16 An: [email protected] Betreff: Re: Public vs. Friend API? 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
