1. RFD: Suggested Enhancement: Namespace
- Posted by Jeff Zeitlin <jeff.zeitlin at MAIL.EXECNET.COM>
Apr 16, 1998
-
Last edited Apr 17, 1998
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
2. Re: RFD: Suggested Enhancement: Namespace
Jeff Zeitlin wrote:
> 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.
That is an excellent suggestion, which to me seems very easily
implementable (an important point).
Although I have been programming in Euphoria for only four months
now, I have often found myself in need of something like that.
Because I have found myself running out of ideas for naming
the globals. For instance I have a dictionary unit, dic.e,
with global constants KEY and ENTRY and function dicFind(),
dicAdd() etc. How much easier if I could just name these
find() and add()! Then I could use the very same identifiers
in a unit implementing, say, a b-tree, or a hash table, or
a sparse array, or... whatever. Right now, the problem is
that global identifiers are "welded" to the file name of the
unit/module. Whenever I think of a more descriptive name
for a particular module I have to change all the identifiers
which refer to the module name. Further, having to type
"dic" every time is not too bad, but, natural laziness helping,
that limits you to using only very short module names, and
you soon run out of significant name, falling into cryptic
abbreviations.
3. Re: RFD: Suggested Enhancement: Namespace
- Posted by Arthur Adamson <euclid at ISOC.NET>
Apr 16, 1998
-
Last edited Apr 17, 1998
>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
Ada handles this problem well...I believe. Art
Arthur P. Adamson, The Engine Man, euclid at isoc.net
4. Re: RFD: Suggested Enhancement: Namespace
I've just read JeffZ's message, and I think I can sum it up in one word:
Overloading. The ability to declare functions with the same name, but with
different parameters, and the ablility, should the parameters be the same,
to discern which .e file they came from.
I know this is possible by passing variable length sequences (that are
possibly type defined before the procedure), but it's not
half as user friendly as being able to do this.
e.g. snippets from non-existent BASICish.e, seqmisc.e and mainprog.ex:
-- MID$ like function(s) in BASICish.e
global function midseq(sequence seq, integer start, integer places)
return seq[start..start+places-1]
end function
global function midseq(sequence seq, integer start) -- Overloading!
return seq[start..length(seq)]
end function
-- End BASICish.e
-- Middle string function in seqmisc.e
global function midseq(sequence seq, integer numofchars)
-- Same parameter types. Oo-er! :)
integer temp
temp = floor((length(seq)-numofchars)/2)
return seq[temp+1..temp+numofchars-1]
end function
-- End seqmisc.e
-- Start mainprog.ex
include BASICish.e
include seqmisc.e
puts(1, midseq("goldfish",3,4)) -- = "ldfi"
-- It's obvious which one this is because it's of type func(seq,int,int)
puts(1, midseq("goldfish",5)) -- causes an error. Which midseq(seq,int)?
puts(1, BASICish.e.midseq("goldfish",5)) -- = "fish"
-- Note that the whole of the name of BASICish.e has to be included
-- because you can call euphoria libraries what you like! ".e" is just a
-- standard imposed by RDS that most of us faithfully follow.
puts(1, seqmisc.e.midseq("goldfish",5)) -- = "oldfi"
-- End mainprog.ex
Just my 2 pence worth (3 1/3 cents) :)
Carl
--
Carl R White - "FBIbait: The President will be castrated in his sleep."
E-mail...: cyrek- at -bigfoot.com / Remove the hyphens before
Finger...: crwhite- at -dcsun1.comp.brad.ac.uk \ mailing or fingering...
Url......: http://www.bigfoot.com/~cyrek/
