OpenEuphoria

overriding vs namespaces

• Posted by Kat <KAT12 at c?osahs.?et> May 15, 2008
• 608 views

Someone once posted a dissertation about namespaces, where internal Eu operators
like + and such were redefined, leading to a much worse mess than one could
possibly make using goto. The maintainability of code where the words don't mean
what you expect leads to Jimmy Carter saying "I have lust for the people of
Poland", and other such problems.

So, despite NOT being paranoid as some about goto (i goto places all the time!),
i vote against *internal* overrides, and suggest the following (which hasn't gone
over well on irc):

Use of namespaces, and no internal overrides.

inside ftp.e:

function ftp_open(types and varnames) : export as "open"

inside sqlite.e:

function sqlite_wrapper_open(types and vars) : export as "open"
}}}
<eucode>

inside LBA_modes.e:
}}}
<eucode>
procedure lba_seek(pointer to 48bit integer) : export as "seek"

inside mycode.exw:

include ftp.e as ftp
include sqlite.e as sql
include LBA_modes.e as LBA
include 
handle = ftp:open(some data about it) -- uses ftp.e's exported "open"
writefile = open(filename,wb") -- uses eu's internal open()
-- etc
sqldata = sql:open(vars) -- uses sqlite.e's "open"
LBA:seek(largereadfile,45000000000) -- uses LBA_mode.e's "seek"
seek(smallreadfile,1000) -- uses eu's internal seek()

I am told this breaks the current:

include ftp.e as ftp
handle = ftp:open(stuff) -- uses ftp.e's open()
handle2 = open(other stuff) -- continues to use ftp.e's open() (!??!)

But i see the code which that breaks as a worse bug than allowing forwards and
reverse referenceing for routine_id(). I am in favor of both directions of
routine_id(). I am not in favor of "sticky namespace referencing", as it's not
explicit, whereas referencing, namespace:overriding, and goto are (local in
scope) explicit.

I believe in overriding in cases where one might want different numbers of
variables passed to a function, but we can handle that with nested sequences in
Eu. And with namespace resolving of "overrides", an include could export an
"open" (or other function names), and code for various parameters and call local
(non-global) functions inside that include per various vars and such.

Cases where an include defines a funct/proc as "global", would still be able to
call that global name. In cases where ":export as "name"" is used, that "name"
would also be available.

I believe my proposal breaks nothing except the sticky referencing, but allows
for namespace resolution of pseudo-overriding.

Kat