RE: private include files
Chris Bensler wrote:
>
>
> 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
>
>
Thanks for the clearer explanation, i am learning more as i follow this topic.
what with talk about backwards compatibilty preventing euphoria from growing
with better features, how about:
making an environment that would run under the new versions but read/translate
the old program to the new environment. other translaters from one language to
another seem to abound. one more won't hurt.
this environment could be like an ide or debugger maybe, where the user could
manually change the settings to see the program variables interactions and tweak
them.
just a thought i had during the middle of my sleep.
rudy
|
Not Categorized, Please Help
|
|
