1. overriding vs namespaces
- Posted by Kat <KAT12 at c?osahs.?et>
May 15, 2008
-
Last edited May 16, 2008
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
2. Re: overriding vs namespaces
- Posted by CChris <christian.cuvier at agricultur?.gouv.fr>
May 15, 2008
-
Last edited May 16, 2008
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
Assume your scheme is implemented. Then someone wishes to extend the abilities
of the Eu builtin "open" by providing some new mode, relying on standard open()
for standard opening modes.
Then, if I got you right, a user of the library implementing that boosted open()
will never be able to call it simply "open", as would seem so natural and was
planned by the library coder. She'll have to use a namespace or other creative
names.
I wouldn't like that at all. So I hope I didn't get you right.
However, what I like is the idea that there must be a way to implement different
behaviour between exported and non exported global symbols. I have pushed for it
for a long time.
CChris
3. Re: overriding vs namespaces
- Posted by jbrown <jbrown106 at ?w?ft-mail.com>
May 15, 2008
-
Last edited May 16, 2008
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
4. Re: overriding vs namespaces
- Posted by Kat <KAT12 at coosah?.n?t>
May 15, 2008
-
Last edited May 16, 2008
jbrown wrote:
>
> 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. :)
Wel, except that i am against overloading the internals, and putting
"overriding" inside namespaces, and ONLY inside namespaces.
> > 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.
It allows for minimal changes to existing code, does not break existing code,
and is the ONLY method for "overloading" an internal function, in my proposal.
For instance, this would be illegal:
junk = open(blah) -- as an override of internal open()
</eucode)
this would be legal inside ftp.e (for example):
}}}
<eucode>
junk = ftp_open(blah): export as "open"
so it can be used like
include ftp.e as ftp
ftp:open(someplace online)
> > 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?
Correct. You could use the "include as name" to spec a new open(), and there's
no way a plain open() would act any differently than the docs say it will, and
you don't need to use internal:open() to use it.
> 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.
So i explained it above some more,, understand now?
Kat
5. Re: overriding vs namespaces
- Posted by Matt Lewis <matthewwalkerlewis at gma?l.co?>
May 15, 2008
-
Last edited May 16, 2008
Kat wrote:
>
> It allows for minimal changes to existing code, does not break existing code,
> and is the ONLY method for "overloading" an internal function, in my proposal.
> For instance, this would be illegal:
> }}}
<eucode>
> junk = open(blah) -- as an override of internal open()
> </eucode)
> this would be legal inside ftp.e (for example):
> }}}
<eucode>
> junk = ftp_open(blah): export as "open"
> </eucode>
{{{
> so it can be used like
> }}}
<eucode>
> include ftp.e as ftp
> ftp:open(someplace online)
> </eucode>
{{{
Actually, this would break some existing code:
-- print.e
global procedure print(...)
-- app.ex
include print.e
print(...)
Matt
6. Re: overriding vs namespaces
- Posted by jbrown <jbrown106 at sw?ft-mai?.com>
May 15, 2008
-
Last edited May 16, 2008
Kat wrote:
> So i explained it above some more,, understand now?
>
> Kat
Yes, thanks for taking the time to do that.
I feel that the ability to override a builtin function (the way it was done in
euphoria 2.2) is quite useful, though. I don't think this should be thrown away.
In your solution, if I have understood correctly, you can't really override a
builtin at all. (You must use ftp:open() instead of open(), and it might as well
be ftp_open().) This is a logical extension of the way namespaces were handled in
2.3 (if theres a conflict, both identifiers must have a namespace qualifier -
except we dont need one for a builtin since it is implied).
It is a good idea.
7. Re: overriding vs namespaces
For overriding existing routines, can I suggest a new Euphoria keyword:
Forget open
This could be used on variables as well as routines.
Arthur Crump
Matt Lewis wrote:
>
> Kat wrote:
> >
> > It allows for minimal changes to existing code, does not break existing
> > code,
> > and is the ONLY method for "overloading" an internal function, in my
> > proposal.
> > For instance, this would be illegal:
> > }}}
<eucode>
> > junk = open(blah) -- as an override of internal open()
> > </eucode)
> > this would be legal inside ftp.e (for example):
> > }}}
<eucode>
> > junk = ftp_open(blah): export as "open"
> > </eucode>
{{{
> > so it can be used like
> > }}}
<eucode>
> > include ftp.e as ftp
> > ftp:open(someplace online)
> > </eucode>
{{{
>
> Actually, this would break some existing code:
> }}}
<eucode>
> -- print.e
> global procedure print(...)
>
> -- app.ex
> include print.e
>
> print(...)
> </eucode>
{{{
>
> Matt
8. Re: overriding vs namespaces
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
9. Re: overriding vs namespaces
Matt Lewis wrote:
>
> Kat wrote:
> >
> > It allows for minimal changes to existing code, does not break existing
> > code,
> > and is the ONLY method for "overloading" an internal function, in my
> > proposal.
> > For instance, this would be illegal:
> > }}}
<eucode>
> > junk = open(blah) -- as an override of internal open()
> > </eucode)
> > this would be legal inside ftp.e (for example):
> > }}}
<eucode>
> > junk = ftp_open(blah): export as "open"
> > </eucode>
{{{
> > so it can be used like
> > }}}
<eucode>
> > include ftp.e as ftp
> > ftp:open(someplace online)
> > </eucode>
{{{
>
> Actually, this would break some existing code:
> }}}
<eucode>
> -- print.e
> global procedure print(...)
>
> -- app.ex
> include print.e
>
> print(...)
> </eucode>
{{{
>
> Matt
How is this new export as construct exclusive to practice of
overriding builtins?
Shawn Pringle
