> This is not true of instance methods, nor is it true of C# extension methods. > e.g., given foo.Foo(), Foo could be defined in foo's class, or in any static > class for which there is a using statement.
And yet it isn't a problem. You won't see the issues that op mentioned with these programming languages. For example: file.close(), you can safely guess it is calling a method close defined inside File class. Even having extensions in mind, is not the rule unlike nim. > The key to readable code is not prefixes, but rather good names that express > the semantics of the thing named. I think that, for certain cases, you can't do much more. File.open and openFile doesn't solve a thing. But, as op pointed out, File.open actually is telling you where was defined open, which is useful when you want to search the body of the function. In the first case, open can only belong to File.