1. RE: private include files
Juergen Luethje wrote:
>
>
> CoJaBo wrote:
>
> > I would have posted this reply much erlier, but the
> > cracker who posted that senseless junk (ALL YOUR
> > BASE ARE BELONG TO US) seems to be crashing my router...
> > (See bBelow)
> >
> > Patrick Barnes wrote:
> >>
> >> On Mon, 11 Oct 2004 21:39:56 -0700, Derek Parnell
> >> <guest at rapideuphoria.com> wrote:
> >>> posted by: Derek Parnell <ddparnell at bigpond.com>
> >>> Has anybody got any thoughts about extending the 'include' system so
> >>> that anything included can only been 'seen' by the file that included
> >>> it.
> >>
> >> It's been brought up before... but nothing has happened of it.
> >> Are there any technical problems with implementing it, Rob? That is to
> >> say, the visibility...
> >>
> >>> private include abc.e
> >>>
> >>> then only the file that has that line can see the 'globals' that are
> >>> defined inside "abc.e". So if another file wants to see them they also
> >>> have to explictly include "abc.e".
> >>
> >> Indeed, that is perfect (or maybe 'include private').
> > I think "private include" would look much nicer,
> > and be less confusing.
>
> 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.
>
> >> If Euphoria did not have to be backwards compatible, I would say
> >> 1-level inclusion like this should be the default behaviour. (with an
> >> 'include global' or something)
> > I am definately against that being the default, since
> > it would cause many of my programs to fail.
> > In fact, I am still using 3 different versions
> > of Win32Lib due to compatability problems...
> > What a headache that is!
>
> On Windows, there are good search-and-replace programs.
> I don't know Linux, but what I read about it now and then, it sounds as
> if there are tools for any situation on Linux anyway. 
> Please keep in mind: Such a change of the language will be "forever",
> and it should be _very_ clean! Half an hour of work for an "old user"
> is little cost for a very clean language.
>
> We already have
> - function/procedure foo()
> - global function/procedure foo()
>
> - object bar
> - global object bar
>
> So it should be
> - include myfile.e
> - global include myfile.e
>
> IMHO it is almost impossible to overestimate the meaning of simplicity,
> readability, and consistency of a programming language!
>
> Additionally, as I wrote in another post, it reads in refman_2.htm,
> 2.4.2 Scope (Euphoria 2.4): "Euphoria encourages you to restrict the
> scope of symbols."
> This is important, and in this context it only can mean, that 'private
> include' should be the default behaviour.
>
> <snip>
>
> Regards,
> Juergen
>
> --
> We don't know where to GOTO if we don't know where we've COME FROM.
> http://www.fortran.com/fortran/come_from.html
>
I agree with Juergen. I couldn't have expressed it better.
If you are going to fix the problem, fix it right.
I for one, would not advocate for 'local includes'. Yes, I've discussed
this issue enough, that I have coined a term for the concept. The
problem is deeper than simply providing a way for people to write more
isolated code. Euphoria does not need more hacks.
I could reiterate what Juergen said, but I won't bother.
I'm glad to see there are other people like me, who actually want what
is best for Euphoria, not just themselves. Breaking compatability, is
not a justifiable argument against such a fundamental change. It's
IMPOSSIBLE to avoid breaking code, if we ever want Euphoria to actually
improve.
One benefit of RDS's infamously glacial speeds of change, is that I can
be confident that this idea doesn't stand a chance of being implemented
any time soon, even if it is popular.
Chris Bensler
Code is Alchemy
HTML or ASCII. Enough with the 10 line signatures. This is a msg forum,
not an art show.
2. RE: private include files
Chris Bensler wrote:
> If you are going to fix the problem, fix it right.
> I for one, would not advocate for 'local includes'. Yes, I've discussed
> this issue enough, that I have coined a term for the concept. The
> problem is deeper than simply providing a way for people to write more
> isolated code. Euphoria does not need more hacks.
>
> I could reiterate what Juergen said, but I won't bother.
> I'm glad to see there are other people like me, who actually want what
> is best for Euphoria, not just themselves. Breaking compatability, is
> not a justifiable argument against such a fundamental change. It's
> IMPOSSIBLE to avoid breaking code, if we ever want Euphoria to actually
> improve.
I have never been able to understand Rob's reluctance to 'break code'.
What code is he worried about? The handful of libraries which come
packaged with Euphoria? How long could it possibly take to change those,
especially considering they would be changed by Rob, who would know
exactly what and how the new features are supposed to work.
If he's worried about breaking other code, such as Win32Lib, well,
first of all, that's not his problem, it's Derek's - and Derek has
been one of the most vocal in requesting changes. Somehow, I don't
think he would mind. As for other less-used libraries, then whoever
actually uses those libraries can either fix them up and submit them
to the archives, or request that the original author or whoever's
willing do so. I can't think of any code in the archives which
wouldn't benefit from a review, anyway.
I think the whole 'might break some code' is a straw-man argument.
Look at other languages where new versions break large amounts of
code - Python and perl come to mind - has that hurt their popularity?
Didn't think so.
> One benefit of RDS's infamously glacial speeds of change, is that I can
> be confident that this idea doesn't stand a chance of being implemented
> any time soon, even if it is popular.
Comparison to glaciers is unfair - to glaciers.
With a glacier, it's possible to predict exactly where they're going :)
Irv
3. RE: private include files
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
4. 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
5. RE: private include files
OtterDad wrote:
>
>
> posted by: OtterDad <otter at full-moon.com>
>
> <Soapbox begins>
> I, for one, applaud Rob's, Derek's and all other coders who insist on
> backwards-compatible code changes. I write commercial applications for
> a very large company. Some code that I wrote years ago is still in use
> today. It gets very frustrating to go back into older code and make a
> minor change only to find out that an update to library xyz now makes
> me debug what was perfectly good code yesterday. I got so frustrated
> that whenever I deploy a program I also catalog every single included
> file along with the program source. This turns a 4k program file into
> a 2 Meg archive. At least this way I know I have the exact copy of all
> code needed to make it work in the future.
> <Soapbox ends>
>
> Yours, OtterDad
>
> Don't sweat it -- it's not real life. It's only ones and zeroes. Gene
> Spafford
Even if the language is backwards compatible, the libraries you use are
not always, you still have the same problem.
The fact that compatability should be broken is not something that
should be considered lightly, I agree. But if the benefit of the changes
made will outwiegh the detriment of breaking code, then it should be
done.
When there are serious flaws in your plan, you will correct them, won't
you? Or you just keep pushing on like a good little steam engine, and
hope that things don't fall apart before you finish?
Chris Bensler
Code is Alchemy
6. RE: private include files
Chris Bensler wrote:
>
>
> OtterDad wrote:
> Even if the language is backwards compatible, the libraries you use are
> not always, you still have the same problem.
> The fact that compatability should be broken is not something that
> should be considered lightly, I agree. But if the benefit of the changes
> made will outwiegh the detriment of breaking code, then it should be
> done.
Compatability with 'old' code is only somewhat important. How often have
you written a new version of some program in another language altogether?
I've done so dozens of times, because my first choice of language proved
to be less-than-optimal. In some cases, the task outgrew the language.
In others, I discovered a much easier/cleaner/faster or otherwise more
productive way to accomplish the job.
I'm certain other programmers have done the same thing. So if changing
languages totally isn't a hindrance, then how can one or two small changes
be all that big of a burden?
> When there are serious flaws in your plan, you will correct them, won't
> you? Or you just keep pushing on like a good little steam engine, and
> hope that things don't fall apart before you finish?
Or, just hire some PR droids to divert attention from the flaws, while
hoping you can cash out before things fall apart. I think that's called
the Redmond Way.
Irv
