On 17 Sep 1999 14:36:26 +0200, Lars Gullik Bj°nnes wrote:
>
>| - My idea here is to restrict messages so as to simply print to a log
>| file/named pipe with a tag that identifies and classifies the message
>| using only standardized functions. The respective gui wizard would then
>| decide how and if the message be presented to the user.
>|
>| Popups are still an obstacle for splitting the code into independent
>| libraries (using only posix functions) and linking as shared objects.
>| Then you would have a separate dynamic library providing the necessary
>| non-standard OS and toolkit interface.
>
>I am not sure how fond I am of the idea of creating a bunch of
>libraries. Why do we need it?
For the same reason every large project uses them. Can you imagine the
rapid progress of 'the gimp' (hundreds of developers) without code (and
responsibility) split through libraries and plugins?:
* Splitting too huge a monolithic code base which has a mess of
interfaces (3,5K exported symbols) reducing them to a small (usable,
learnable, maintainable) fraction.
* Speeding up development, by:
* using many small maintainable modules,
* hiding *all* implementation details in
internal headers,
* using 4 or 5 small interface headers with
externally opaque simple ADT instead of 500
with visibly exported complex data structures.
* Splitting up responsabilities, by:
* using 'programming by contract',
* sharing burdens ('one man one library'),
* reducing complexity ('black box principle'),
* providing for rapid changes in the core developer team.
>OS/2 can have them if wanted, but on
>UNIX it will make the installation process harder and more errorprone.
You can't use archives (*.a ) for static linkage???
Even if you have provided for them, nobody is forced to
actually link dynamically. The main purpose is speeding up development.
>| - Defining strict and simple inter-library interfaces providing
>| abstract data types and simple functions as well as starting to
>
>We are not interestet in inter-library interfaces, but in inter-module
>interfaces. We care ding about libraries.
I'm sure the inter module interfaces will soon become too complex (now
you have 3 1/2 thousand global interface symbols, soon you'll see
10,000 or more. If you want to live with that...
But then don't expect much progress in stable releases....
[BTW: Many modules like figinset.C are even now far too large with more
than 2000 lines of codes and hence too hard to maintain. I think, 300
lines of code are a reasonable limit that should never be exceeded.
Many wizards (like e.g. E.Mattes, who nearly alone wrote the huge Unix
interface EMX for OS/2) propose more radically: One function, one
module!]
Best wishes for your baby :-)
Arnd
