OpenEuphoria

RFD: Suggested Enhancement: Namespace

• Posted by Jeff Zeitlin <jeff.zeitlin at MAIL.EXECNET.COM> Apr 16, 1998
• 741 views

A while back, I got bit by a notbug.

It turns out that my Frames library and Jiri Babor's Font library
have conflicting procedure names.

Ordinarily, this could be 'solved' by editing one of the .e files
to avoid the name conflict - but this is a short-sighted route,
and will not be practical in all cases - for example, if one is
using shrouded .e files from several sources.

Without some sort of namespace management capability, all library
developers for Euphoria will necessarily need to be familiar with
_all_ existing library code, so as to avoid such name collisions.
As more and more Euphoria code is developed, this will become
impractical (if it is not already).

Modula-2 offers this kind of capability through its normal IMPORT
mechanism - one can code

=46ROM Frames IMPORT fprint;
IMPORT Font;

and be able to use the fprint procedure from both, by coding

fprint(...);

to use the Frames procedure, and=20

=46ont.fprint(...);

to use the Font procedure.  This would be a good model to follow
in Euphoria.  However, to match the model in detail would render
it incompatible with 'legacy' Euphoria code.  To maintain
compatibility, I propose a 'reflection' of this model:

Normally, one includes library code in Euphoria by coding

include font.e
include frames.e

and the procedure names are imported unchanged.  This would be
maintained.  To qualify the names of the public symbols in a
module, I propose that one should code

include font.e using fn

A library included in this manner would have its public symbols
qualified for external use by prefixing them with the characters
fn_.  Note that this maintains absolute compatibility with prior
code.

Euphoria already appears to have some of the necessary capability
built-in - library global variables and library internal
procedures are already maintained separately from the general
namespace.  This would reasonably appear to be implementable as
an extension to that capability.

--
Jeff Zeitlin
jeff.zeitlin at mail.execnet.com