On Wed, Feb 18, 2015 at 9:52 AM, Gordon Sim <g...@redhat.com> wrote: > On 02/18/2015 02:28 PM, Rafael Schloming wrote: > >> On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim <g...@redhat.com> wrote: >> >>> To amplify a little, the point was that the two things currently in the >>> utils module are ways of adapting the reactive, non-blocking, >>> event-driven >>> style to some other style (messenger is in my view a similar sort of >>> thing). Though it is certainly more narrow, I think its also more >>> helpful. >>> >>> The other aspect to these is that they aren't yet considered as >>> fully-baked as the reactive core. I certainly don't object to them being >>> in >>> an extras namespace to denote that, until we are more comfortable we have >>> the interfaces right. You could also however indicate that through >>> documentation or some 'experimental' annotation. >>> >> >> >> I agree we don't necessarily need to signal bakedness in the package name, >> I think it's good to think of it as an orthogonal dimension. I'm not quite >> sure I follow the reasoning for proton.adapters though. That sounds to me >> like somewhere we'd put stuff for integrations, e.g. maybe the tornado >> stuff. >> > > I see these things as providing an alternative API on top of the reactive > style API. Which to me is what an adapter does. > > To me the tornado integration is more of a plugin. > > I'm not adamant about the 'adapters' name though, just saying its clear to > me(!). I really don't like 'contrib' though. For one thing it makes no > logical sense to me. How are things more 'contributed' than anything else? > I think 'extras' is actually a clearer way to describe the layering you > mention. I don't mind that, though it is a little vague. (I think an > adapter is also clearly layered).
I can't speak to the logic, but I believe the use of contrib to signal pretty much *exactly* what we are talking about here is a pretty common convention. There's a post here that describes django.contrib in much the same terms: http://jacobian.org/writing/what-is-django-contrib/ If we didn't already use the contrib convention I wouldn't actually care all that much, but I feel like we should at least be consistent within our own codebase, so if we introduce python.extras, that's pretty much pushing for a rename of the java contrib stuff which seems like unnecessary churn at this point. I do get the impression that there is possibly an unspoken bias against contrib, i.e. that's just a bucket to stick unwanted contributions, but I really don't think we should view it that way. I think the comments in the post above about it only containing best practices and what not are something we should take to heart. --Rafael
