Crossing namespaces

[Daniel van Vugt]

Thomas,

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 canonical.com> 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 lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>