[RFC] Solid and use of namespaces

Marcos Mayorga marcos at mm-studios.org
Mon May 22 13:10:44 BST 2006


I would choose using namespaces to nest the classes.
Clearer code, best designed, improved readability and extensibility, and
over all, increases the level of abstraction, which is a key factor for
OOP.

ie: I have nothing to do with the class PowerBattery related to 'power'
if you choo to use power::battery, a can later do a power::solar_panel,
and use functions insife power (like power::have_i_supply_for_one_hour())
which abstract me on the specific power supply the instance is using.


I vote for this, if valuable,
thanks



> On Sunday 21 May 2006 18:19, Thomas Zander wrote:
>> On Sunday 21 May 2006 16:50, David Faure wrote:
>> > > I mostly fail to see the need for namespaces, it feels like
>> > > overdesign without any clear advantage, since C++ does not provide
>> > > many features in the user of namespaces.
>> > > And if the advantage is Power::Manager instead of PowerManager and
>> > > Power::Battery::isFilled() instead of PowertypeBattery::isFilled(),
>> > > well; its too similar to actually accept disadvantages in my
>> > > experience.
>> >
>> > The difference is that in a .cpp file you can do
>> > using namespace Power;
>> > Manager(...); Battery::isFilled();
>> > etc.
>> > which avoids filling the file with "Power" everywhere.
>>
>> Oh, sorry for not being clear; I am aware of that, indeed. In the part I
>> wrote above I meant to say that I'd rather have 'PowerManager' and
>> 'PowertypeBattery' in my sources then the ones you have.
>> I firmly believe that using namespaces to such an extreme will hinder
>> readability of the sources.
>
> In an example like the above, yes. But reading 1000 times "KIO" in the
> kio sources, or "KParts" in the kparts sources, wouldn't really improve
> readability in any way.
>
> --
> David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice
> (http://www.koffice.org).
>






More information about the kde-core-devel mailing list