OpenEuphoria

Re: Enhancements to the include system

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Dec 16, 2006
• 715 views

Chris Bensler wrote:
> Ok, from what I understand there is no change in syntax. Just that when a
> collision
> is encountered, the most closely 'related' definition is used to resolve?

The main idea is that if something works stand-alone, it will work the same 
when included in a larger application. All the information needed to do that
is embedded in the include statements needed to make it work stand-alone.

Barring, that is, stuff you cannot really ever expect to handle such as
conflicting library version dependencies, say liba only works with
win32lib 0.59.1 but your app or libb only works with >= 0.60.4.

Actually, I have introduced a new class of problem... I've allowed forward
routine calls, and automatic includes of standard things, so you can say

s=sort(s)

without getting "sort has not been defined".
The snaglette I've introduced is that if sort.e is automatically included
by libX standalone but has been overridden by the calling application, I'll
either get the same old namespace qualifier required error, or it may start
to use the sort() defined in the app, when by my rules it should not...
There is even/however a simple fix, write a "sortstub.e" file:

include sort.e
include libX.e

<snip>
>it still only seems to cover a portion of the problem.
<snip>
>even if it doesn't address the global contamination issue at all.
<snip> 
> In 5 or 10 or however many years, if or when eu has 100 or 1000x as many
> programmers,
> will a namespace solution be sufficient to deal with global contamination and
> still allow people to share code freely without alot of conflict hassles?

Well, in a word, yes! There are two types of problem to be dealt with:

a) You have to modify Your code to use libX, or a new version of it.
b) You cannot use libX without modifying it.
   (Case b covers the case of libY defining one or more globals with
    the same name as one(s) defined in libX and applies to libY if
    you were thinking of modifying that to avoid modifying libX.)

I am only talking about solving b). Moaning about a) is, well, just 
moaning .

Regards,
Pete