On Fri, Feb 13, 2015 at 11:15 AM, Gordon Sim <g...@redhat.com> wrote:
> On 02/13/2015 03:00 PM, Rafael Schloming wrote: > >> This has come up tangentially in a couple of threads now, and there seems >> to be at least tacit agreement that the plural doesn't make sense anymore >> now that we've seen how integrations/extensions will work. >> >> I'll be posting an alpha later today, but before that I'd like to do the >> reactors->reactor rename of the python package to keep everything >> consistent. This stuff hasn't been in a release yet, so I don't think >> there >> are any backwards compatibility issues, but if this will cause problems, >> please follow up and I will create an alias. >> > > Just a suggestion, but what about proton.reactive? Perhaps proton. > handlers could then be proton.reactive.handlers, which would make the > relationship clearer. > I'm fairly neutral on proton.reactive vs proton.reactor. I do kind of like the notion of a "proton.reactor", mostly because it sounds like something awesome that is used to power starships, however that isn't a huge deal. I'm less of a fan of nesting handlers, partly just because it's longer, and partly because it complicates the mapping to the C API which like most C APIs is just flatter. Another option favoring conciseness and consistency with C might be to get rid of the "reactor" portion entirely: - proton.Reactor, proton.Container, and proton.handlers.* All in all I'm not super fussed, I could probably live with any of the options. I did already do the reactors->reactor rename, but it's easy enough to do it again if any of the above seem significantly preferable. --Rafael
