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
