Re: Include system
> Subject: Re: Include system
>
>
> posted by: Chris Bensler <bensler at nt.net>
>
> ags wrote:
> >
> > Hi All
> >
> > I've just had a thought about the include system, well an observation
> > really.
> >
> > A program in a sub folder of an include file can say something like:
> > }}}
<eucode>
> > include ..\file_one.e
> > </eucode>
{{{
> > Which sucessfully includes a file from one directory level up.
> >
> > But if that file_one.e includes another file from the folder it is in, eg
> > file_two.e,
> > the interpreter will not be able to locate it.
> >
> > What is to stop the interpreter automatically searching the folder an
> > include
> > is actually in for any includes that file looks for?
> >
> > Or would this break things? (even more 
> >
> > I say this because of making library distributions--if you want to keep any
> > demos in a sub folder you would want to include ..\something.ew (or include
> > ..\include\something.ew) but if that file in turn includes stuff then things
> > get broken.
> >
> > Gary
>
> No, it wouldn't break anything.
> I beleive this issue is one of the final frontiers for the evolution of
> Eu's physical include system, and I've been suggesting (or wanting to, I
> can't remember though I'm sure I mentioned it at least a few times) it
> for a long time. I never really pushed it though since it first required
> being able to use subfolders for includes, which is only officially
> possible since 3.0.
>
> I've implemented it in my preprocessor and I'm trying to implement it in
> the Eu opensource, if I can ever manage to spend enough time to figure
> out Robs code.
>
> Here is how it works in my preprocessor to give an idea for those who may
> not understand what is being talked about. Maybe someone else with more
> experience with the Eu source code can implement it...
>
> All I do in my preprocessor is keep track of the active include folder.
>
> Currently Eu searches for includes
> 1. in the program folder
> 2. in the EUINC paths
> 3. in EUDIR/include path
>
> With relative include paths Eu would search
> 1. in the active include folder
> 2. in the program folder
> 3. in the EUINC paths
> 4. in the EUDIR/include path
>
> PS.
> Just MNSHO, but I don't suggest using ..\ in an include statement,
> although I can see the reason, it may not be avoidable and is not of
> particular concern if the lib will only be used in a particular project.
> Doing so means that the subfolder is bound to the parent folder.
> I wouldn't say it's taboo, but it should be considered with the same
> weight as using global declarations should.
>
> Sorry, I can't fully explain why it's not desirable, but I can say that
> you can do that sort of thing in PHP and I've found it to be problematic.
> I've been avoiding having to code that way in PHP for a few years, so the
> issue is rather vague now. Take it with a grain of salt.
>
>
> Chris Bensler
> ~ The difference between ordinary and extraordinary is that little extra
> ~
> http://empire.iwireweb.com - Empire for Euphoria
>
>
If I understand Chris' proposal correctly,, nothing would be broken.
ACTIVE_PATH would be set to the demo folder, but program folder wouldn't
change. So, if ..\file_one.e includes file_two.e, the attempt to search
ACTIVE_PATH will fail, but using the program folder will succeed as it
did when finding file_one.e
A safaty net could be to try all the include path stack items, but this
shouldn't be necessary I think.
As for using .. in include statements, it sure makes the library design
more rigid, since - for instance - the demo will always have to be in a
subfolder of the main include files folder. My take on this would be to
have environment based symbolic names available for inclusion. Like
system("set main_folder=..\\",2)
include $main_folder\file_one.e
The $ syntax exists in other languages; I'd go along with about any
other scheme which doesn't require too much typing, as Eu often forces
to.
CChris
--
cchris005 at fastmail.fm
--
http://www.fastmail.fm - The way an email service should be
|
Not Categorized, Please Help
|
|
