Re: Too many namespaces
- Posted by LarryMiller Sep 16, 2013
- 3706 views
Prior to the introduction of namespaces Euphoria had a serious problem. Whenever a program used a third party include file there was always the possibility, and in the case of larger files, the likelyhood of a name clash. In many cases the only solution was to rename the clashing function, procedure, or other public symbol. This was tedious and error prone. Having multiple include files from different authors only compounded the problem. As an ideal a programmer should be able to treat an include file as a black box. It should never be necessary to even look at the files contents, let alone modify it.
Adding a prefix to public symbols was a viable but far from ideal solution. It greatly reduces the chances of a clash but doesn't really avoid them completely. Win32lib is a case in point. The code is littered with w32this and w32that, the only purpose being to avoid name clashes. It worked but wasn't what you would call elegant. But with Euphoria as then existed there really was no practical alternative.
Namespaces were a simple and elegant solution. Whenever there is a clash all a programmer needs to do is specify the namespace followed by the symbol name, as in "namespace:routinemame(). By default the namespace is the same as the name of the include file. If this produces a clash the programmer can override this name as necessary. Instead of trying to avoid the name clashes it provides the means of dealing with them. A programmer can use include files as they are without massaging them to avoid name clashes. An include file author can use names that fit their function instead of worrying about name clashes. Many other programming languages use similar methods.
I am not saying that namespaces are a perfect solution. In this imperfect world perfection is something that we strive for but never really achieved.
Using a namespace for each include fills the need. Having fewer namespaces would reduce the chances of a name clash but wouldn't avoid them. And at the same time it would add a few new ones.
But all of this is academic. Namespaces have existed in Euphoria 4.x for a long time and many applications rely on them as they currently exist. It would require a really compelling reason to change this now. To date no one has even come close to providing one.
