Crossing namespaces

[Daniel van Vugt]

I think making things more complicated (deeper namespaces) is not an 
ideal way to make them easier to understand. Maybe hold off on that.


On 03/07/13 18:21, Thomas Voß wrote:
> On Wed, Jul 3, 2013 at 12:16 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> Umm, no. I don't recommend making the namespaces any deeper than they
>> already are :)
>>
>>
>
> Hmmm, why not? It's arguably a very good way to classify components
> into different categories (which is the purpose here, iiuc) and
> namespace aliasing helps in avoiding spelling out deep namespace
> hierarchies.
>
>
>
>>
>> On 03/07/13 18:11, Thomas Voß wrote:
>>>
>>> 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