Re: Enhancements to the include system
- Posted by Chris Bensler <bensler at nt.net> Dec 16, 2006
- 693 views
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