Deimos: Consistent structure?

[Martin Nowak]

On Tue, 22 Nov 2011 13:00:31 +0100, mta`chrono  
<chrono at mta-international.net> wrote:

>> Making "import deimos.ncurses" import everything is just wrong. NCurses
>> consists of 13 libraries. 4 of them are the most important to the user
>> (developer): curses, menu, panel and form. Importing panel if you never  
>> use
>> NCurses panels is pointless I think. It is not a big library though...
>>
>> ...
>
> I think in this case "import deimos.ncurses;" should _NOT_ be available.
> It's pointless, I agree in what you said. It needs to be devided into
> serveral modules.
>
> import deimos.ncurses.curses;
> import deimos.ncurses.menu;
> import deimos.ncurses.panel;
> import deimos.ncurses.form;
>
>
 From /usr/include:
ncurses.h -> curses.h
curses.h              | basic header
panel.h               | includes curses.h
form.h                | includes curses.h and eti.h

It makes sense to follow that pattern and wrap up everything under
deimos.ncurses or ncurses. Having an ncurses package currently disallows
to have a ncurses module under the same path, so this is no option.

martin

> --------------------------
>
> 1. smart library bindings
> Those bindings that fit in a _single_ module. They consists of a single
> source file and can be imported via "import deimos.libname;"
>
>
>
> 2. bigger library bindings
> They _don't_ fit in a single module and therefore they provide different
> modules. they can be imported via "import deimos.libname.sub1; import
> deimos.libname.sub2; ..."
>
>
>
> 3. aggregation of bindings
> In _some_ cases it seems to be useful if you can import _all_ modules at
> once. deimos.libname.sub{i} is renamed to deimos.libname_.sub{i} and a
> dummy deimos.libname is added to import them all at once.
>
>
>
> I'm very interessted in your personal opinion. So: Free for comments :-)