| I just want to reiterate how completely a non-issue this is. It is so much of a non-issue, that it took me this long to even get the slightest inkling of what your worry is. The reason that it is a non-issue is how often do you need to import two external functions with the same name that have different meaning into the same file at the same time? It does happen, but not so much that it is an issue. With Python, for instance, there is sys.path and os.path. So what? I refer to one as sys.path and the other as os.path. BFD. And there's the join method on strings and os.path.join. Since one's a method and the other's a function in Python, you're right that if methods were called like functions in Python, there'd be a potential namespace conflict, but I'd just continue to refer to one as join and the other as path.join. I do that now anyway, so nothing would change! Or let's take the example of draw. If we're only talking about drawing to the screen, then all of the draw methods can implement a common generic function. There's no problem. On the other hand, if I need to use both the "draw on the screen" draw and the "draw your gun" draw, then I'd import one as drawOnScreen and the other as drawYourGun. If overloading in supported, then there's no need even to do renaming. You can just use draw all the time and the type system will know which draw is applicable for the type in question. Once again, no problem. In summary, your worry is just not a problem! |