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.
|
Not Categorized, Please Help
|
|
