I guess I shouldn't be able to use %do on any such script from console anymore?
sorry: do instead of %do
Ladislav
just use INCLUDE
(it actually even finds the script for you, as opposed to DO which does not have a search capability)
for example, I write:
include %timblk.r
and do not care where the script is, since INCLUDE finds it for me
DocKimbel
How does it avoid collisions between similar script names in different include folders?
Gregg
It does mean relying on INCLUDE as a normal part of your workflow and approach, but I would have a hard time giving it up now.
You can use the #include-check directive to catch multiple includes, so your include-path gives you control.
Ladislav
it uses the INCLUDE-CTX/PATH search path variable, where the first found first served approach is used. Also, you can adjust your path at any time, which is being done by some scripts to "shrink" the search area
...and you can alway just write: INCLUDE-CTX/PATH: [%.] which uses only the current directory for search
Gregg
I would like to see INCLUDE be standard, perhaps with a refinment on DO (or just have it work that way by default), simply because INCLUDE doesn't imply execution the way DO does.
DocKimbel
Gregg: I use the same workflow for my REBOL work since 10 years...it's uneasy to change that, unless I can convince myself that the gains are worth the effort of changing the habits. :-)
Ladislav
Well, Gregg mentioned that he would not want to give up on INCLUDE because it saves time in a significant way
Gregg
I'm the same way. It took me a while to transition to INCLUDE, but I'm glad I did.
DocKimbel
Ladislav, last question: do you think it is possible (and desirable) to easily build INCLUDE features in R3 in a transparent way for the user? I mean that for example DO would intrinsicly use INCLUDE when having to access a file.
Gregg
How much benefit you see will depend on what you're building, too. My two main needs are apps that need to be encapped (often with different features whether for local use or as a rich 'net app), and scripts that comprise elements in larger systems, where there are common infrastructure elements and libraries, but scripts are run dynamically.
I think so, but I could be wrong. :-)
Put another way, is there a reason it couldn't?
In that scenario, I would think about how it would work in the wild, with resources made available on the 'net. An elegant integration of modules, INCLUDE, and public libraries would be a dream come true.
DocKimbel
I guess we could also overload DO in R2 to make INCLUDE usage almost transparent.