> On May 19, 2015, 2:02 a.m., Ben Mahler wrote: > > This might be a valid namespace alias use case that we hadn't considered, > > because there is no way to be able to write just `http::Response` > > otherwise, is there? > > > > Seems quite verbose to write process::http everywhere, and on the otherhand > > just having `Request` or `Response` seems to miss the context of it being > > http, thoughts? > > Michael Park wrote: > > This might be a valid namespace alias use case that we hadn't considered > > I actually think we should reconsider the overall approach of disallowing > aliases (e.g. type, namespace). > > because there is no way to be able to write just http::Response > otherwise, is there? > > We could do so by declaring `using namespace process;` if we wanted to. > > Seems quite verbose to write process::http everywhere and on the > otherhand just having Request or Response seems to miss the context of it > being http > > This is the entire point of aliases in general, which is why I think we > should reconsider the decision to disallow them. > > thoughts? > > From a offline discussion with BenH, it seems like the decision to > disallow type and namespace aliases to avoid inconsistencies in different > files. For example, one person could write `namespace http = process::http;` > and another person could write `namespace phttp = process::http;`. > > I think the correct solution is to come up with naming guidelines to give > them good and consistent names, rather than disallowing the feature. For > example, we don't disallow functions just because "someone could possibly > give it a horrible name". We instead try to influence people to give their > functions meaningful names in a consistent manner. An example of such rule is > that we write `member()` rather than `getMember()` for our getter functions. > We don't simply disallow getter functions just because people could say them > inconsistently. > > Anyway, given the current rules, I would push for us to be consistent > with no special cases. Especially since we have much longer names all over in > the codebase that we cope with. (e.g. `mesos::master::allocator::Allocator`, > `&master::allocator::MesosAllocatorProcess::deactivateFramework`, > `master::allocator::HierarchicalDRFAllocator`) > > I'm definitely interested in starting the discussion around reconsidering > the rules and perhaps formalizing some of the naming rules around aliases, > but I also think that that should happen outside of this review, probably in > a JIRA ticket.
Sounds great Michael! Happy to help you get these aliases added, at least restricted to this use case initially. :) - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34375/#review84251 ----------------------------------------------------------- On June 13, 2015, 9:51 p.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34375/ > ----------------------------------------------------------- > > (Updated June 13, 2015, 9:51 p.m.) > > > Review request for mesos and Till Toenshoff. > > > Repository: mesos > > > Description > ------- > > See summary. > > > Diffs > ----- > > src/master/master.cpp 3049e057c87571f5db73ee0b14db8b47132b2dff > src/slave/slave.cpp 9af69d8f0b28c9441c684886c52320378f9b2869 > src/tests/master_tests.cpp ba3858fb3026f2cc7af0523bd1a0c541eeafc34b > src/tests/slave_tests.cpp 8dae6e0842c2bedddc13d1c036390e85c7a96df7 > > Diff: https://reviews.apache.org/r/34375/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Michael Park > >
