OpenEuphoria

Re: Namespace clobbering internals

• Posted by Shawn Pringle <shawn.pringle at ?mail.c?m> May 02, 2008
• 787 views

If you set builtins as always being the one used when a namespace is not 
specified you will break overloading.  If you leave the interpreter the 
way it is, your new library's use of functions with the same names as 
builtins will break much more code than what's in print.e.  A 
third alternative is to introduce some kind of hiding into a namespace.
A fourth alternative involves avoiding any builtin names.

When I say, hiding objects into a namespace.  I would like you to 
suppose that insert() is a routine defined in db.e.  
'include db.e' means you can only access db.e's insert() function as insert().
'include db.e as db' means you can access db.e's insert() function as 
both insert() and db:insert().  You could hack  the backend such that
that allows you can get access to insert() as db:insert() but not as 
insert().  I don't like the idea of modifying the backend, though.

The fourth alternative is, you can use the same method names over and over if
you
ensure they are not builtins.  All new libraries can use routines names
over and over so long as the name doesn't appear twice in the same file.  So,
you may need to find synonyms for some builtin names but you only need to find
one synonym for each one.  There is no modifying the backend and you wont break
any existing code.

The fourth alternative, I have to say is less bug proned than the third
alternative
since you are not modifying the interpreter C-source itself.  You don't need
to put the builtins into their own namespace because you purposely avoid using
builtins.  This means that large programs like Judith's IDE could use it without
renaming or namespaceing other things.

The third alternative has appeal to me.  I think it would be neat to do a kind
of overloading only for things inside a namespace.  You might introduce bugs
into
the EU interpreter but large programs could then use this library without
renaming
or namespacing other things.

The first two ideas are well understood by anyone who reads Matt's posts so I
will
not talk more about them here. :)

Shawn