Re: private include files

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu