> Well, then it is useless. I am from a domain (science) where similar concepts
> are generally called a similar way and where clashes occur a lot because
> something as simple as * has a gazillion meanings depending on the context
> (and all of them applied to arrays of any dimensions, so no useful dispatch
> there).
Maybe this is exactly where the context is. Nim allows you to use types and
overloading unlike languages such as python. Generally speaking when type of
the argument does not encode the context, you should use a more explicit name.
I can give a bad example:
proc open(arg: string): auto = ...
It does not tell you what it actually opens. Since the module is not generally
prepended to function calls, I would recommend to encode what is actually meant
to be opened in the Name:
proc openFile(filename: string): auto = ...
Now it is more clear that the function is supposed to open a File, but still it
doesn't tell what it actually opens.
proc openTexture(filename: string): Texture ...
proc openDocument(filename: string): Document ...
proc openSoundSample(filename: string): SoundSample ...
But when using object oriented programming, overloading can be used again:
proc open(self: var Document; filename: string): void = ...
proc open(self: var Texture; filename: string): void = ...
proc open(self: var SoundSample; filename: string): void = ...
var myDoc: Document
myDoc.open("myfile")
Now it is clear what the naked open does, depending on the Type of the first
argument. Maybe you should pack your naked arrays into objects, so that you can
use overloading to define the meaning of the operation you want to do. Maybe
you are just too used to put everything in just an Array, because you got used
to do that from Fortran so much, but maybe that is simply not the best practice
in other programming languages.
