[fdo-dev] Namespace

[Greg Boone]

While this discussion is quite interesting and does give the FDO
community something to think about, there are no immediate plans to move
towards namespace usage in FDO. Current development should continue to
use the class prefix naming convention.

Greg

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Saturday, August 12, 2006 9:10 PM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] Namespace

Traian Stanev wrote:
> Hi Mateusz,
> 
> FDO already uses a short prefix to class names to accomplish the same
>  effect.

Traian,

Prefixes and namespaces are different features, so I can not agree they
cause the same interchanging effect.

Sure, John Lakos in his book [1] is trying to proof prefixes superiority
but this book is from 1996. Namespaces were intruduced to C++ in 1993,
so this argumentation does not make sense today.

[1] Large-Scale C++ Software Design, 1996

> All Fdo core classes use Fdo as prefix to class names for example, 
> while for example classes in the SDF provider use the Sdf prefix. 
> What would namespaces add to that, apart from more complexity?

In my opinion, it would simplify many things.

Shortly as I can, I see following cons of namespaces over prefixes:

a) keep names short and short names are easier to remember,
short names help with grasping project internals and in daily
communication

b) namespaces can be easily nested, see point 1)

c) namespaces can help in API versioning; version number can be used as
a part of namespace name, for example today I use fdo alias with
following value:

namespace fdo = ::FdoApi_3_0

and some day I release new API, so I can alias it in some files as
follows:

namespace fdo = ::FdoApi_4_0

and all code that uses fdo namespaces stays unchanged.

d) namespaces help to easy reorganize files/classes/nested namespaces in
future, what's really helpful in fast-development-cycle, like XP or
prototyping. So, you can move classes or namespace from one to another
and use namespaces aliases to make your existing code compilable (and
delay refactoring till you have more time), but new code can use new
layout.

c) better readability - namespaces and using directives may help to keep
code compact and clear so more readable, without long-lines, verbosity
and tedious parts.

d) namespaces help with better orthogonality, so it's much safer
construction than static types in translation-unit-scope.



Namespaces analysis regarding my last FDO experiences:

1) simplify the physical structure of FDO

C++ namespaces help to organize components like packages do in Java.
Good practice is to organize project physical layout following
namespaces structure, where every sources directory represents single
namespaces, top-level or nested. Such projection is essential to
navigate (faster) through huge projects. So, it's a nice simplification
and you can only see the #include <foo/bar/club/bingo.h> line
to know where to navigate to get to file with Bingo class.
You don't need to do many cd-and-check to Module/Inc/AnoteherModule
or may be Unmanage/Module/Src/YetAnotherModule/SubModule, and so on.


2) make it easier to maintain sources in future

This has been already answered in point 1), because clear physical
structure makes daily work easier.
If case of names conflict, when using prefixes, you will need to
change more places than when using namespaces.

3) provide clearer and stronger modularization of FDO components

clearer, in terms of 1) and 2) but stronger in terms of coding-time and
 compile-time.


4) help new users to grasp the FDO internals faster

I know something about it :-)
>From my experience, I can compare FDO learning curve with
other C++ libraries like Boost, Spirit and GEOS.
For example, nested namespaces and physical
modularization of GEOS components was very helpful for me when I was
starting to contribute.


5) avoid "hungarian notation"-like problems

Prefixes share the same problems as hungarian notation. It's well
explained in Microsoft MSDN documents about new coding style introduced
with .NET Framework and recommended by Microsoft.


Actually, I've found FDO prefix-based naming convention as a real
pain for me as a newbie. 40-chars long names are very hard to learn and
remember when analysing new code, like:

FdoRdbmsMySqlDataStorePropertyDictionary
MySqlOvGeometricPropertyDefinition



The only disadvantage I see is possibility of polluting
namespaces with unreasonable usage of 'using' directives.
But it can be avoided if simple rules are respected:
- never use 'using' directive in header
- use 'using' in translation units only
- use 'using' inside function bodies

I'm just sharing some of my opinions arising while discovering FDO.

Best regards
-- 
Mateusz Loskot
http://mateusz.loskot.net


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org