[DGD]Initializing problem

[Jason Cone]

> -----Original Message-----
> From: Erwin Harte [mailto:harte at xs4all.nl]
> Sent: Friday, April 20, 2001 10:38 AM
> To: dgd at list.imaginary.com
> Subject: Re: [DGD]Initializing problem
> 
> Not sure.  I would probably also include defines in that file that
> could be useful for objects in other /usr directories, at which point
> I'm not sure which is easier/better to work with, this one:
> 
>   # include <System.h>
> 
> Or this one:
> 
>   # include "~System/include/System.h"


For each of the 2 locations, /kernel/include/System.h and
/usr/System/include/System.h, the statement,

	#include <System.h>

, is still a valid declaration; I verified this by moving your System.h from
/kernel/include to /usr/System/include and changed nothing else.  Because
one of the (secondary) include paths in the config file is "~/include", any
file that is represented by "/usr/<single directory>/include/<file>" can be
included via "#include <file>".


> I think the /include/System.h file should give general pointers into
> the /usr/System/ tree, while ~System/include/ would contain include-
> files for specific objects' interfaces.


Granted.  It could also be argued that including a non-standard file in the
core library directory structure is no different than modifying a core
library file. ;)  Plus, should Felix decide to ever include a
/kernel/include/System.h file (for whatever reason), that would necessitate
breaking compatibility for those secondary libraries that were employing the
underlying functionality of the core library _and_ originally implemented a
/kernel/include/System.h as suggested by the supplied setup.

To me, a custom secondary library should be totally and completely
encapsulated by the /usr/System -- that way, alternative core libraries
could be developed on top of which any library that was configured to run on
top of Felix's core library could also run (which may, or may not, contain a
'/kernel/include' directory).

For what it's worth, I think you performed a great pedagogical service by
supplying what you did -- for more people (myself included), it's much
easier to learn by example than by theory. :)

JC

--
  Jason Cone
  Senior Software Developer
  Usability Sciences Corporation
  Voice: 972.550.1599
  Fax: 972.550.9148
  Email: jcone at uscdev.com 

List config page:  http://list.imaginary.com/mailman/listinfo/dgd