Re: include statement bugs
Robert Craig wrote:
>
> Derek Parnell wrote:
> > Do you believe that two files always have the same content if
> > the have the same name but reside in different folders?
> >
> > For example, given these two files ...
> >
> > myfolder\abc.ew
> > yourfolder\abc.ew
> >
> > do you believe that their contents must therefore also be
> > identical, just because their names are the same?
>
> The second include is ignored on the assumption that they
> are essentially the same. ("belief" that they are "identical"
> overstates things a bit)
As an aside, I used the word "believe" rather than "assume"
because I want a clear statement of your beliefs/philosophy.
So to summarize, Euphoria will assume that any two files that have
the same name will also have the same contents.
> > If not, will v2.5 use the entire canonical path name when it
> > determines whether or not to instantiate a new included file?
>
> No it won't.
I am very saddened to hear this. Not because it effects my work, but
because it describes a mindset that I'm not comfortable with.
> I consider this to be a tiny issue that affects maybe 1% or less
> of all programs. I think it took several years for anyone to
> even notice how it works. How many people want to include two files
> in one program, where the files have the same name, but
> different content?
I was thinking more along the lines that, for example, I distribute
win32lib that happens to include a file called "text.e". Some person
installs win32lib and also installs Bill's text editor library, that
coincidently also has an include file called "text.e". My "text.e" and
Bill's "text.e" have nothing in common and have been developed
independantly.
Why should the person who is attempting to use these two libraries be
hindered by Euphoria's file-name assumption?
> As I think back 10 years or so, I think I did it
> this way because I didn't want:
> graphics.e
> .\graphics.e
> ./graphics.e
> c:\euphoria\include\graphics.e
> \euphoria\include\graphics.e
> c:graphics.e
> to be considered "different" files, leading to
> multiply-defined symbol error messages,
> when in fact they might be exactly the same file,
> or at least a copy of a file. I didn't want to write code
> to resolve the paths, to prove that one of them was in fact
> the same file as another.
I can see and agree with your intention, but the lack of effort to
resolve this is a worry. Making the assumption must save a few
milliseconds for <1% of all programs.
> If this bothers you, just rename one of your files (and avoid
> confusing the reader of your code).
Why do you assume that they are 'my' files and that I am in a
position rename them? They could have been provided to me by two or
more independant developers, and could be shrouded.
> By the way, this and the backslash vs. forward slash thing
> can be changed easily by anyone in the new source code.
And will be!
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
