Crossing namespaces

[Daniel van Vugt]

Ping. Any movement on this discussion?


On 03/07/13 18:43, Daniel van Vugt wrote:
> 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
>