OpenEuphoria

Re: Packages

• Posted by CChris <christian.cuvier at agri?ultu?e.gouv.fr> Aug 07, 2007
• 551 views

jacques deschênes wrote:
> 
> 
> CChris wrote:
> > Because simple systems won't work.
> > They will create issues of their own, out of short-sightedness.
> 
> oh! really, what are the issues with C# namespace system? which is essentially
> what I propose.
> 
> 
> > Mine has less typing, and requires less namespaces, so it is simpler. Yours
> > does not address the problem of existing code which doesn't use namspaces at
> > all. 
> 
> No at all the namespace system I propose, won't brake any legacy code,
> namespace
> qualifier could be only use as needed.
> And the original namespace system will stay valid.
> 

I was not implying that legacy code would break, but that it would keep causing
trouble because of its uncontained identifiers.
In my system, current namespacing is valid and semantically untouched. The
current namespacing works well for multiple file applications, but more poorly
for multiple file libraries. That's why it needs being complemented - not
replaced.


> incluce  libxx.e as xx  -- would stay valid
> 
> or if my proposol is implemented
> 
> include  libxx.e [alias xx] -- no need for an alias here but accepted.
> 
> the if there is a name clash
> [somename:]fctX()
> here "somename" is namespace identifier defined at top level in libxx.e and
> one
> use it only there is a name clash as it now implemented in euphoria.

So you need to edit existing code to make it behave? That's exactly what I
strive to avoid, for obvious reasons explained in the paper.

> But with this system a namespace is not limited to a single file, It applies
> to any global identifier defined inside:
> 
> namespace somename
>   ...
> end namespace
>  
> 

What happens when namespaces are nested? Since this is internal to the library
and may change without notice, the user shouldn't have to bother and use
compound, possibly changing, namespaces at all - he shouldn't have to use any,
for that matter. For something you may forget - SIMPLICITY OF USE OF THE LIBRARY.

> regards,
> Jacques Deschênes

Additionally, this scheme doesn't appear to address the poroblem of namespace
pollution. Once a library defines a symbol, even if namespaced, you won't be able
to define one of your own and perform an unqualified call. Forcing to use a
namespace on the user is clumsy, and is problematic since namespace identifiers
are not inherited by inclusion.
Extension of global routines, which implies redefining them, doesn't work
either.
Unless you have written something elaborate enough to check for the tricky
details, which are galore.

CChris