Re: Enhancements to the include system

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

Chris Bensler wrote:
> 
> Pete Lomax wrote:
> > 
> > CChris wrote:
> > > 
> > > I wrote in some detail about enhancements I plan to make to the current 
> > > include system. This appears on the relevant  EuWiki page in the 
> > > "Requested functionalities" category as solution #2.
> > If talking about with package=myLib: var1, proc_xyz,... friend, share, 
> > restrict, redefine, then imo completely the wrong approach, see 
> > my comments (3 * "||" markers) on that page.
> > 
> > Regards,
> > Pete
> 
> Since you ask..
> 
> Sorry, but I have to agree with Pete concerning your solution, it's too
> complicated.
> I don't think I agree with forcing the use of qualifiers though. The concept
> of pkgs might be useful, but I'm not sure how at the moment. Mainly I think
> the problem of global contamination can be resolved with a much simpler and
> robust solution.
> 
> I saw your proposed solution before, but refrained from commenting because I'm
> much too opinionated, especially regarding this topic and my opinion is rather
> biased on the matter.
> 
> For those who are lost, the article is here:
> <a
> href="http://euwiki.ayo.biz/Improved_scoping">http://euwiki.ayo.biz/Improved_scoping</a>
> 
> I wrote that article stub btw (with the exception of solutions #1 and #2) and
> have a complete plan laid out in my mind yet to be explained, including the
> use of chained include statements, the use of include subfolders (already
> implemented
> in 3.0) and relative include paths (likely to be implemented soon) among a few
> other things. I'm finishing it in private when I have time, to avoid the
> confusion
> of the different proposals.
> 
> In any case, it's clear that there isn't any kind of consensus on how to deal
> with global contamination, so I would hate to see any solution rushed into,
> including my own. I'm pretty sure Pete's implementation is unique from both
> of ours and I can think of at least a handful of other people with their own
> unique views on this too.
> 
> 
> Pete: I didn't see your description of the implementation for Positive.
> Can you reiterate the concept or point me?
> 
> Chris Bensler
> ~ The difference between ordinary and extraordinary is that little extra ~
> <a href="http://empire.iwireweb.com">http://empire.iwireweb.com</a> - Empire
> for Euphoria

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.

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

Search



Quick Links

User menu

Not signed in.

Misc Menu