Re: overriding vs namespaces
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.
Namespaces and operator overloading are completely unrelated. I agree with you,
lets not go there. :)
>
> 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>
{{{
The only bit of your proposal that is new is the use of "export as" which did
not appear to solve anything.
The conversation moved fast, and I may have missed the part where you explained
what it was to be used for.
>
> 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.
Agreed. This particular example should break.
>
> 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.
>
In other words, you are against allowing builtin routines to be overriden?
If this is limited to files which are included into a namespace, this is
acceptable. Builtins and namespaces never fit well together.
> 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.
This probably the case. True overriding of builtins + use of namespaces is
probably rare enough that we effectively don't have to worry about it.
I still don't see why export as is necessary.
>
> Kat
|
Not Categorized, Please Help
|
|
