Crossing namespaces

[Thomas Voß]

Fair point. I'm +1 on mir::server::${SUBNAMESPACE} as a first go to
reflect the directory structure.



On Wed, Jul 3, 2013 at 12:09 PM, Daniel van Vugt
<daniel.van.vugt at canonical.com> 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