OpenEuphoria

Re: Do you currently use namespaces?

• Posted by CChris <christian.cuvier at a?riculture?gouv.fr> May 26, 2008
• 1096 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > Matt Lewis wrote:
> > > 
> > > Since both files need depend upon the code, it's just being more explicit 
> > > about things.  
> > > 
> > 
> > This is completely against modular programming.
> 
> Wrong.
>  
> > If fileB.e depends on any file that provide something, but is meant to be
> > included by them, you'll have fileA1.e and fileA2.e which will include
> > fileB.e. Fine.
> 
> Your pattern is broken.  This would be equivalent to win32lib (old days) 
> relying on the application to define the handler sequences, like onClick.
> Instead, we have a procedure in win32lib, setHandler, that the program
> calls to set the variables.
> 
> Most languages (OK, that's an unproven assertion, but I can think of at
> least C/C++, java, perl and python) wouldn't even let you get away with 
> this.
> 
> > But now, what to code in fileB.e?
> > 
> > include fileA1.e -- but fileA2.e might do as well
> > or
> > include fileA2.e -- then what about the possibiity for fileA1.e?
> > 
> > True, you may use the new ifdef statement to choose which one. But this
> > misses the core point.
> > 
> > The core point is that you need to know the name of a file to include it.
> > But you don't know the name of all the third party files that might benefit
> > from including fileB.e, since what is needed is only some properties of
> > the including file. This goes against reusability of fileB.e.
> 
> Again, your pattern is broken.  You should expose an API for those that use
> your library to supply whatever initialization stuff you need.  You also
> get the free bonus that you don't require that more symbols be global.
> 
> Matt


The construct is perfectly valid in 3.1, and would serve a definite purpose, ie
implementing plugin file schemes. Perhaps removing this ability will not actually
break code. But I see no benefit to offset the loss.

CChris