On Apr 14, 2013, at 23:58 , BJ Hargrave <[email protected]> wrote: > > A sidenote on the RFC 197: I think naming these annotations more > > explicitly like "ProviderImplemented" and "ConsumerImplemented" > > would reduce confusion on which to use when. > > Naming is always fun :-) I personally prefer the current names. They are type > annotations.
I like the current names better as well, but I am not 100% satisfied with them. ;) Yes, we are talking about types, so having that in the name of the annotation makes sense. We are also talking about decoupling providers and consumers of an API and the specific role that each interface has in that context. Let's use EventAdmin as an example, a bundle P that provides that service and a bundle C that consumes it to send and receive events. In bundle P: EventAdmin is implemented (or "provided"). EventHandler is invoked (or "consumed"). In bundle C: EventAdmin is invoked (or "consumed"). EventHandler is implemented (or "provided"). You see my point? Depending on if you're looking from bundle P or C, it's easy to use the exact opposite verb for the same interfaces. So the names are context dependent. Of course a specification can easily explain this, but "provider" and "consumer" are overloaded terms. Another attempt at naming: In bundle P: EventAdmin is a "ProviderImplementedType". EventHandler is a "ProviderInvokedtype". That, to me is more clear, but it still leaves us with a choice, since we could also have gone for: In bundle C: EventAdmin is a "ConsumerInvokedType" (instead of "ProviderImplementedType"). EventHandler is a "ConsumerImplementedType" (instead of "ProviderInvokedType"). If I had to choose, I would go for a "consumer oriented" description of APIs in general, assuming more people consume rather than implement an API, and go for he "Consumer…" names because of that. Greetings, Marcel
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
