To most non-programmers, JohnSmith, john_smith and JOHN_SMITH all
denote the same person. As programmers, we unlearn this identity to
make them different. When looking up a name, XL ignores case and
separating underscore '_' characters (two consecutive underscores are
not allowed).
// There is only one 'file' and one 'open_file' below
function OpenFile(string Name, Mode) return file
FILE F := open_file("foo.dat", "r")
On the other hand, name overloading allows you to reuse the same name
for different entities when the name will not be used in the same
context.
type rectangle
function Rectangle(integer X, Y, Width, Height) return rectangle
rectangle Rectangle := Rectangle(10, 10, 20, 20)
In addition, XL, like any Mozart-based language, requires a renderer,
which can be used to present code to programmers with their preferred
style.
Why? Style preferences cause religious reaction from many otherwise
reasonable programmers. Style insensitivity allows reuse of libraries
while maintaining a consistent style in your own code.
Cons: Entities that would be distinguished by case in the real world
can no longer be distinguished this way. For instance, V for volume
and v for speed in physics. This is common and reasonable practice.
An interesting idea, indeed. Python's lack of a naming style annoys
me a great deal -- I'd be happy to use any naming style, if there were
any reason to pick one over the other. Even the standard library has
nothing approaching a standard naming style (there's even capitalized
method names).
But there is no reason to pick one over the other. The only standard
we have is CamelCase class names, and (except for the very occasional
exception) method names start with lower case letters. After that all
bets are off.
Anyway, style insensitivity seems like a cool way to deal with it.
Maybe it would be annoying if there wasn't contextual names (like the
in the rectangle example). But maybe not so bad either.
Previous Topic
