Sturmlilie
commented
3 years ago I'm a little torn on the FooAPI.barAPI thing, on the one hand it's clear, on the other hand it feels a little redundant? Like FooAPI.bar would suffice? Do you have an opinion on this?
No opinion, and if this was my personal project, I'd have done it exactly as you described. Just kept the variable names the same to get feedback on a neutral basis. Though I've been accused of "making variable names too short / conscise" in the past, so I need someone else to push back against it =P
fnuecke
Based on the discussion in #104.
What I care about: Having the APIs be grouped by sidedness, and being passed as a grouped unit to the respective extension initializers. This is all about the API consumer (ie. the extension writer) having a strong guarantee of initialized resources. No null checks should be necessary, except if the passed API bundle is to be used anywhere else outside the initializer. In this case, the onus of null checking falls on the API consumer.
What I don't care about: Class names, variable names, and where the internal reference to the initialized API (for dog fooding) is stored. If you have any other wishes aside from what you already touched upon, I'm happy to oblige.
The API interfaces from
detail/have been moved up, as they are now the center parts accessed by the consumer, replacing the static entry points both in location and usage.I will make a few more comments inline regarding decisions other than naming that I already find questionable.