[E-Lang] Name mangling

[Ravi Pandya]

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.

Ravi

-----Original Message-----
From: Marc Stiegler [mailto:marcs@skyhunter.com]
Sent: Monday, May 21, 2001 12:28 PM
To: Ravi Pandya; e-lang@mail.eros-os.org
Subject: Re: [E-Lang] Name mangling


Ravi,

Great to hear from you in this forum, with a live E app! :-)

Markm is out of town for a couple of weeks, so I will give you a brief reply
here of my understanding of why we are following the Python conventions.
Basically, some people on the list were having trouble with name conflicts
because the names were simple names one might use for other purposes. (was
it Tyler who had a problem? I am not skilled enough with pipermail to find
the thread). Markm adopted the Python conventions with the simple goal of
having a justification for his choice that would avoid endless rounds of
argumentation about why the name was X not Y: if someone asked why the name
was foo, it was because it followed the Python conventionas closely as
possible inside the framework of E.

I am sure that markm will be delighted and eager to make your usage of E as
smooth and effective as possible, but it will be a couple weeks before he
can engage this question.

--marcs

> I can see the reasons for copying the Python classifications and
formalisms
> for the operators, assuming they have been well thought out and have stood
> the test of time. However, I don't see a strong reason for adopting their
> double-underscore name mangling convention, especially since (a) it is not
> being adopted exactly, and (b) the probability of automated translation
from
> Python to E is essentially zero. The one reason could be that the more
> ordinary names are more likely to cause a conflict with existing code, but
I
> think any existing usage is likely to be very similar to the E usage if
the
> names are well chosen, and the code readability argument seems more
> compelling to me.