Why are opCall's not implicitely assignable?

Mike Parker aldacron71 at yahoo.com
Tue Sep 26 10:10:43 PDT 2006


Karen Lanrap wrote:
> Mike Parker wrote:
> 
>> make your code as readable as possible.
> 
> Without any measure of readability this requirement is as useful as 
> the word user-friendly.
 >
 > COBOL is known as a language where everything is extremely readable.
 >
 > C and some other languages are known to be more readable than D
 > because they distinguish between pointers ( ^, -> ) and fields ( . ).
 >
 > A dialect of BASIC declares itself to be more readable by allowing
 > the point to be part of identifiers ( "a.b.c" is one legal
 > identifier).
 >
 > Txl replaces "f(g(h(p)))" by "p[h][g][f]".
 >
 > Must I mention APL? ( to me its close to brainf***)

Sorry, our wires are crossed. "readability" in the sense of brace 
location and other syntactic issues isn't what I'm getting at. I'm 
talking more about self-documenting code:

void a();
void b();
void c();

What do the above methods do? Unless you see the implementation, you 
have no idea. Function names that are named clearly and are indicative 
of what they do in a given context should be plenty clear to anyone 
reading them. You can't divine the details without looking at the 
implementation, but all you need to know is that a method named 'print' 
will take its input and format to an output location somewhere. opAdd in 
the D world clearly is not the overload for the * operator. This is the 
readability I'm talking about.

Abusing the property syntax by trying to assign colors to 'roof' and 
'seat' properties, which clearly aren't colors, is unreadable in the 
sense that it makes the 'roof' and 'seat' properties appear to be Color 
objects. Someone reading the code cannot see what is going on without 
looking at the implementation details of the Car class.

Whether or not they go cross-eyed from Lisp braces is another issue.




More information about the Digitalmars-d-learn mailing list