Re: Enhancements to the include system
Pete Lomax wrote:
>
> 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
> }}}
<eucode>
> s=sort(s)
> </eucode>
{{{
> without getting "sort has not been defined".
I think automatic inclusion is a bad idea.
One of my golden rules for a programming language or most any program for that
matter, is that it should never make assumptions. Assumptions cause confusion at
the very least.
> <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 
.
I agree, you should never have to modify third party code. It's one of my
principle philosophies for modular programming.
Here, again I must point out that you are addressing how to better resolve
collisions (while at the same time increasing confusion), not how to prevent them
in the first place (reducing confusion).
Currently the Euphoria codebase is pretty tiny. The more code that is available,
the more collisions there will be. The more collisions there are, the more
namespacing will be required.
Euphoria is very wasteful in it's use of globals. It creates alot of
contamination for no good reason and at the same time forces the programmer to
have to expose certain declarations that are only intended for cross-file use
among the API they are developing. A large portion of global declarations in an
API that consists of multiple files are for internal use only or they are just
index constants for some sequence structure.
Firstly, if Eu had at least some kind of ability to name the members of a
sequence, that would help tremendously. I'm unresolved on how to deal with
structured sequences, but my preference is to implement namespaced codeblocks and
aliases (in fact, if I had my way I would eliminate the include namespace
mechanism in favor of codeblock namespacing) and forego any ability for typed
sequence members. This would work for naming members of a structured sequence by
allowing a declaration in the namespace with the same name to be inherited.
namespace rect
sequence rect
alias left rect[1]
alias top rect[2]
alias right rect[3]
alias bottom rect[4]
end namespace
I'm not actually happy with how I've used alias in that example, since in my
mind an alias should simply be a way to create another name for a declaration,
but the example makes it a macro. I'm working on it.
Using namespaced codeblocks, if someone wanted to recreate the include
namespacing that Eu uses now, you would do something like..
namespace FOO
include myFoo.e
end namespace
Notice that you would also be able to define multiple includes into a single
namespace using that method.
Second, a way to isolate how far a global declaration should extend *by the
developer who declared it*, would add a great deal of control. This has to do
with my idea for chained includes, or global chaining, in other words. It's too
much to explain here.
Third, the ability to gain access to 3rd party declarations that were never
intended to be global would create an additional way that declarations could be
internally shared among files of an API without exposing them globally or forcing
a programmer to modify foreign code. This is more for creating flexibility while
preserving code and is perhaps more of an enhancement than anything to do with
reducing global contamination, but I think it's related. Again, I'm not going to
get into my idea for implementation at the moment. The purpose of this post is to
point out the issues that need to be recognized. I'd like to encourage ideas and
proper resolution, not enforce my own.
I'm probably missing some other possibly better ways that global contamination
could be reduced but these are the ones that I think would work best. Not only
that, but they would enhance the language, not just fix problems.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
|
Not Categorized, Please Help
|
|
