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