OpenEuphoria

RE: private include files

• Posted by Chris Bensler <bensler at nt.net> Oct 13, 2004
• 475 views

Pete Lomax wrote:
> 
> 
> On Wed, 13 Oct 2004 08:06:31 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
> 
> >It will be confusing anyway, because there is no "private procedure", or
> >"private object". E.g. Hayden McKey is already confused, _before_ this
> >feature is actually implemented.
> 
> That's a very interesting point.
> 
> The problems we are discussing here are not really about "hiding" a
> global the author /intended/ to make publicly available, but about not
> exposing things the author needed to make visible throughout all the
> code of the library component, but "global" unintentionally makes them
> visible externally.
> 
> Forgetting what has been said about 'global include' and 'private
> include' for a moment, try this on for size:
> 
> A private procedure or object would be visible inside sub-includes,
> similar to global variable handling, but would be removed from the
> symbol table at the end of the file that defined it, which is more
> like local variable handling.
> 
> The sneaky bit is that when a file is "privately included", then these
> private variables do NOT disappear, but become visible until the end
> of the including file. Package-level, if you like.
> 
> Regards
> Pete
> 

The Euphoria scope currently works like this..
Global (program scope)     -- spans all scopes
-Local (file scope)        -- spans a particular include file
--Private (routine scope)  -- spans a particular routine
---Block (loop scope)      -- 'for' loops, specifically

The scope that is missing is group scope. NOT private scope.
Euphoria lacks the ability to include a file across a regulated domain 
of files.
What is being proposed for 'global include' would change global from 
program scope to group scope. There would be no universal program scope. 
It should never be needed. Any good programmer will tell you that global 
scope should be avoided at all costs. Create interfacing procedures if 
you have to, just so you dont 'have to declare a variable as global. 
Does that really sound like the current implementation of global is 
effective? Most of the time, we are battling to get around it, not use 
it.

Include private is no better than our current namespacing solution, 
which is practically useless. At best, local includes would alleviate 
the problem by creating a new one.
Just like namespacing, you would be required to specifically include a 
file as local in each file that requires it. How do you deal with a 
local file that is included multiple times across several source files? 
Should each source file have their own instance, or should they all 
share the same local file? If they share, then it's not a local file 
anymore is it?

Besides, as juergen pointed out. Local includes does not follow the 
character of Euphoria. In contrast, global include compliments 
Euphoria's existing scope system. It's not just a hack to make it work. 
It's a real solution.

People need to stop trying to defeat the backwards compatability issue, 
and accept that Eu must change to be better.

I would hate to see the same mentality with my mechanic. "you got a big 
dent or scratch? Just put a sticker on it"
A new fender might cost me some bucks, but how many times can I put a 
sticker on my rusty scratches? For that matter, how many stickers can I 
plaster on my car before the integrity of my autobody is deteriorated 
beyond any possible recovery?

Euphoria's foremost characteristic is elegance. Consider that first.
Elegance doesn't just mean pretty and simple. It also means stable and 
homogenous. Local includes does not fit well in Euphoria's existing 
structure. The very reason WHY euphoria is simple, is because it's 
design is based on very few concepts, which are used well.
When I think of elegance I think of ballroom dancing. There are no 
sudden movements, everything flows and the dancers are symbiotic (they 
act as one).
Euphoria's elegance is the reason most of us are using Euphoria.

I personally, would argue against any solution geared at circumventing 
issues with backwards compatability. Deal with the compatability, and we 
will have a much more desirable and effective Euphoria.


Chris Bensler
Code is Alchemy