Re: Enhancements to the include system

new topic     » goto parent     » topic index » view thread      » older message » newer message

CChris wrote:
> 
> I had thought for a while that using priority rules (defining what closeness
> 
> is and resolving unqualifird symbols to the closest one known) was enough.
> Indeed, this is how the specs for Open Euphoria (v1.2) were written. This 
> schme definitely looks practical.
> 
> However, it was pointed out at the time (by Matt I think) that such a solution
> 
> would induce an unwelcome sensitivity to the shape of the inclusion tree, 
> and would make maintaining large libraries more complex because of subtle 
> bugs creeping in, while the purpose was to make that very acttivity easier.
> This is why the scheme(s) I described hardly rely on closeness rules now.
> The only thing I kept was localness (if a global is define in the same 
> file, use this symbol). So, while I trust your solution to be well thought,
> 
> I'm afraid that it makes maintainance/evolution of packages needlessly tricky.
> 
> Why not chime in in the Wiki?
> CChris
> 
> 
> PS: I moved the comments in "Improved scoping" to the talk page of that 
> article, since I understand it is the very purpose of these talk pages.

It's kind of baseless to disagree with this namespace solution on the grounds of
complicating the include dependencies since we already deal with this issue
routinely for any library which depends on another.

I agree, it does create a level of uncertainty in code.
However, this can be dealt with by issuing a supressable warning instead of a
fatal error. That is the only difference from how eu currently works.

The warning would be to the unqualified calling code, since the warning needs to
be controlled by the third party, not the library that creates the conflict.

Eg.
[fileA]
global constant X = 'A'
[/fileA]

[fileB]
global constant X = 'B'
[/fileB]

[fileC]
include fileA
include fileB

without conflict

? X -- should echo 66

with conflict

[/fileC]

I think Pete said that he wouldn't allow that particular behaviour like in my
example, since fileA and fileB are equal in the hierarchy. Not allowing equal
files to override another would help enforce hierachal domination.

The real issue that this solution deals with is the need to declare a namespace
at every level that a colission occurs, regardless if it's been previously
qualified in another file, not really global contamination.
Although namespacing is meant to resolve the global conflicts, it doesn't
prevent them. (see my rant about 'Evil' Namespacing in the Improved Namespaces
wiki article)


Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu