Re: private include files
- Posted by Patrick Barnes <mrtrick at gmail.com> Oct 13, 2004
- 433 views
On Tue, 12 Oct 2004 19:03:03 -0700, Hayden McKay <guest at rapideuphoria.com> wrote: > > posted by: Hayden McKay <hmck1 at dodo.com.au> > > I dont think that it is really all that nessaccary to have global includes > > I like how you can make each include file run completely independant of > other include files handled by the program. Each include file has its own > set of decleared variables and routines. A global include would make all > the functions/procedures, variables etc.. available to all the includes > handled by the program, this would defeat the purpouse of a private include 'global include' is not what you're describing it as. Global include is the default behaviour in Euphoria now... If you include a file into your library, then another library that includes your library will automatically have visibility of the global routines in the first file. When the end programmer includes the second library, they have visibility of the global routines, constants and variables in library 2, library 1, and the original included file. This is responsible for most of the namespace problems in Euphoria. Almost all of the time, the programmer only needs access to the things in the library that is included, NOT those in subsequent files. The only exception I can think of, is when a library needs to be broken up into.--- nope, all of the user-visible parts should be in the base library.... The only exception I can think of then, is when a set of constants needs to be shared ---- that's a bit hazy even, shouldn't the programmer include them directly if needed? The thing is, that when there are exceptions, then 'global include' can be explicitly used... and I can't see it being used much. -- MrTrick