[E-Lang] Name mangling

[Ravi Pandya]

Something like opAdd is readable enough that I could probably live with it
as the single Java interface.

Another idea for handling existing classes: wrappers for specific classes
and interfaces that map the E conventions to whatever that class supports,
e.g.

/**
 * Singleton class that implements any operators that make sense
 */
class Set__EWrapper extends DefaultEWrapper
{
    public Object opAdd(Object set, Object other) {
        if (other instanceof Set) {
            Set result = new HashSet((Set) set);
            result.addAll((Set) other);
            return result;
        } else {
            // throws an exception
            super.opAdd(set, other);
        }
    }
    // etc.
}

Registering such wrappers could be a problem. I suppose the interpreter
could try all interfaces and superclasses for the __EWrapper variant, and
cache the result if successful.

Ravi

-----Original Message-----
From: Dean Tribble [mailto:tribble@e-dean.com]
Sent: Tuesday, May 22, 2001 10:43 AM
To: Ravi Pandya
Cc: e-lang@mail.eros-os.org
Subject: RE: [E-Lang] Name mangling


Below are random ideas that I am not advocating, but merely throwing into
the pool....

At 10:19 AM 5/22/01 -0700, Ravi Pandya wrote:
>If we've already run into a case where there's a conflict, in such a small
>group of developers, then it's more common than I thought. In that case, it
>is probably best to keep the name mangling, ugly as it is - a conflict in
>classes you can't change is a show-stopper, whereas maintaining two sets of
>names is only an inconvenience.

A compromise might be to use the other proposed naming: "opAdd" rather than
the more annoying "op__add" :-)

An alternative that I hesitate to suggest:  have collections and numbers
(the most common utilities) have reasonable names in Java, and map them to
op_blah in the E sugaring layer.