OpenEuphoria

Re: overriding vs namespaces

• Posted by Shawn Pringle <shawn.pringle at ??ail.com> May 17, 2008
• 585 views

This is just the thing that is missing.  Right now, you either have
the function go into the global namespace, no namespace or the
global namespace and named namespace.  It cannot yet go into only
a named namespace.

Shawn Pringle

Kat wrote:
> 
> 
> 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:
> }}}
<eucode>
> function ftp_open(types and varnames) : export as "open"
> </eucode>
{{{

> 
> inside sqlite.e:
> }}}
<eucode>
> 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"
> </eucode>
{{{

> 
> inside mycode.exw:
> }}}
<eucode>
> 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()
> </eucode>
{{{

> 
> I am told this breaks the current:
> }}}
<eucode>
> 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() (!??!)
> </eucode>
{{{

> 
> 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