Subject: Crossing namespaces

From: Daniel van Vugt <[email-masked]>
Date: Wed, 03 Jul 2013 18:00:58 +0800

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.

---

From: Thomas Voß <[email-masked]>
Date: Wed, 3 Jul 2013 12:08:01 +0200

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
<[email-masked]> 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.
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 03 Jul 2013 18:09:55 +0800

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.

---

From: Thomas Voß <[email-masked]>
Date: Wed, 3 Jul 2013 12:11:30 +0200

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
<[email-masked]> wrote:
>>> occurs

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 03 Jul 2013 18:15:54 +0800

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:
>>> see

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 03 Jul 2013 18:16:29 +0800

Umm, no. I don't recommend making the namespaces any deeper than they 
already are :)

---

From: Thomas Voß <[email-masked]>
Date: Wed, 3 Jul 2013 12:18:07 +0200

On Wed, Jul 3, 2013 at 12:15 PM, Daniel van Vugt
<[email-masked]> wrote:
> 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.
>

That sounds good to me, I just wanted to point out that we should
focus on the immediate requirements :)

Thomas

---

From: Thomas Voß <[email-masked]>
Date: Wed, 3 Jul 2013 12:21:31 +0200

> Umm, no. I don't recommend making the namespaces any deeper than they

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.

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 03 Jul 2013 18:23:27 +0800

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

---

From: Thomas Voß <[email-masked]>
Date: Wed, 3 Jul 2013 12:28:31 +0200

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
<[email-masked]> 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.
>
>
>

---

From: Daniel d'Andrada <[email-masked]>
Date: Wed, 03 Jul 2013 07:30:22 -0300

> namespace aliasing helps in avoiding spelling out deep namespace

Just my two cents:
I think namespace aliases (like "mc", "ms" and so on) hamper readability 
(eg:"hey, what that 'xyz::' prefix stands for again... let me check its 
declaration at the top of the file") and are a sign that those 
namespaces are actually getting in your way instead of helping you out. 
IMHO, if they are not solving naming clashes and are repeating 
information (e.g. foo::FooController instead of just foo::Controller) 
they your're not really gaining anything from them.

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 03 Jul 2013 18:43:31 +0800

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).

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 22 Oct 2013 15:57:39 +0800

Ping. Any movement on this discussion?

On 03/07/13 18:43, Daniel van Vugt wrote:
>>> ideal
>>>>>>> underneath src/server/. So if they're used outside of the server
>>>>>>> then
>>>>>>> we
>>>>>>> should fix that too.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> trying to trace server logic through multiple subdirectories,
>>>>>>>>> which
>>>>>>>>> it