Crossing namespaces

Daniel van Vugt daniel.van.vugt at
Wed Jul 3 10:15:54 UTC 2013


To answer your question properly... I'm not proposing an immediate 
change. But then again, waiting until it's "required" is arguably never, 
or arguably right now.

The code needs to be as readable and maintainable as possible, as soon 
as possible, so as to not make it slow and painful for new people to 
come in and understand before they can use it or contribute. Like I'm 
trying to do with various server classes, right now.

- Daniel

On 03/07/13 18:09, Daniel van Vugt wrote:
> I should also mention the below namespaces/directories are already
> underneath src/server/. So if they're used outside of the server then we
> should fix that too.
> On 03/07/13 18:08, Thomas Voß wrote:
>> Hey Daniel,
>> I think pulling everything under mir::server is difficult as some of
>> the functionality is shared with the client and potentially testing
>> infrastructure, too. My proposal would be that we refactor into more
>> appropriate namespaces if required/when severe issues are encountered.
>> Doing a full sweep right now seems to be overkill to me.
>> What do you think?
>> Thomas
>> On Wed, Jul 3, 2013 at 12:00 PM, Daniel van Vugt
>> <daniel.van.vugt at> wrote:
>>> Looking through our class hierarchies, particularly in the server, it
>>> occurs
>>> to me that we cross namespaces a few times. This is particularly
>>> apparent
>>> trying to trace server logic through multiple subdirectories, which it
>>> crosses a lot. I'm referring mainly to:
>>> mir::graphics::
>>> mir::compositor::
>>> mir::surfaces::
>>> mir::frontend::
>>> These namespaces are often so related and interdependent that I can't
>>> see
>>> the justification in them being separate. It just makes things more
>>> complicated. And if they should be separate then they're not quite
>>> separated
>>> in an optimal way yet.
>>> Does anyone have a good reason why server classes shouldn't live under
>>> mir::server:: ? I don't imagine many of the sub-namespaces are really
>>> required or even logical any deeper than that.
>>> --
>>> Mir-devel mailing list
>>> Mir-devel at
>>> Modify settings or unsubscribe at:

More information about the Mir-devel mailing list