Crossing namespaces

[Daniel van Vugt]

Certainly, we have cases where the namespace is an integral part of the 
class name right now. Cases like those can't be merged into a single 
namespace unless you change the class names too (which I encourage).


On 03/07/13 18:28, Thomas Voß wrote:
> I think making a deeper hierarchy does not conclude into complexity.
> Trying to think in a flat mir::server namespace, I would think that it
> is likely that we will end up with something like Graphics*
> class/struct names as opposed to having a graphics:: namespace. Of
> course, both is valid, but Graphics* is just very redundant and
> syntactic noise in the end.
>
> On Wed, Jul 3, 2013 at 12:23 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> 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