[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Vlad,
I wonder, couldn't you just override the return type of the getModule method (i.e. use a covariant return type), assuming that erlide modules would extend IModule?
I was thinking about a good name for a while, before IModule came to mind. I'm not saying the name cannot be changed, but I'm in lack of a good alternative... I realize that such generic term as "module" can cause ambiguities, but ISourceModule would not be quite correct, since the concept was introduced specifically to allow for "binary modules" (e.g. "IClassFile extend ISourceModule" would look a bit bogus IMO). Before IModule, I was agonizing around something like ISourceHost, which is abstract enough, but seems a bit ugly.
Any suggestions for a better name?
Thanks,
Vladimir
Hi!
I have a small problem with the new IModule, that I didn't realize it would be a problem...
In Erlang, the unit of modularity is a module and my elements had a getModule method. Now This collides with ISourceElement's method and I have to rename it to getErlModule, which is not so nice because all other API doesn't have the "Erl" particle.
I realize it is a bit late to complain and suggest to rename it to ISourceModule or something similar, but I'll do it anyway :-)
best regards,
Vlad
