On Tue, 22 Nov 2011 13:00:31 +0100, mta`chrono
<[email protected]> 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 :-)
