1. overriding vs namespaces
- Posted by Kat <KAT12 at c?osahs.?et> May 15, 2008
- 609 views
- 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
- 589 views
- 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
- 576 views
- 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
- 594 views
- 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
- 593 views
- 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
- 589 views
- 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
- Posted by Arthur Crump <arthur.crump at nt?world.co?> May 16, 2008
- 573 views
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
- 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
9. Re: overriding vs namespaces
- Posted by Shawn Pringle <shawn.pringle at ?mail?com> May 17, 2008
- 582 views
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