Notes IV

Jarrod qwerty at ytre.wq
Fri Jan 25 00:30:11 PST 2008


Okay you wrote a lot of stuff, and I generally agree for a lot of it, but 
I disagree for a few things.

 
> 1) In D I often enough do mistekes like this: foreach (i, a, myobj)
> But usually not this one:
> foreach (i; a; myobj)
> There for my eyes it's not always easy to spot the difference between
> "," and ";", so I think a "in" instead of ";" (as used in Python and C#
> too) can be seen better: foreach (i, a in myobj)

I don't really see what this fixes. It seems you just prefer to use 'in' 
because you're used to python.

 
> 3) In my D code I keep writing "length" all the time (currently I can
> find 458 "length" words inside my d libs). It's a long word, $ inside
> the scope of [] helps reducing the typing, but I often enough write
> "lenght", so I think still a default attribute named "len" (as in
> Python) may be better than "length". The attribute "dup" too is an
> abbreviation, probably of "duplicate", so abbreviations seem acceptable
> in such context.

'len' is kind of ugly, something like 'size' would be nice.

 
> 4) Use + instead of ~

No. + means add. Not concatenate. I really don't want to see + being used 
as both the addition operator and concatenate. A different unused 
operator maybe like a comma would be fine if you think a tilde is an 
uncommon keyboard input character, but not a +


> 12) In Python functions are objects, so you can add them attributes: def
> foo(inc):
>   foo.tot += inc
>   return foo.tot
> foo.tot = 10
> foo(10)
> print foo.tot # prints 20
> 
> So is it a silly idea to allow public static variables in D functions,
> to do something similar?
> 
> int foo(int inc) {
>   public static int tot;
>   foo.tot += inc;
>   return foo.tot;
> }
> void main() {
>   foo.tot = 10;
>   foo(10);
>   printf("%d\n", foo.tot);
> }

Couldn't you just make an object for this in the first place? I don't 
want to see functions being used as objects when they should be.. well, 
functions.


> 18b)
> Here indentation doesn't follow the program meaning: if (x == 0)
>     if (y == 0)
>         foo();
> else
>     z = x + y;
> 
> In Python such possible source of bugs is absent, because the
> indentation is the only important thing, so this:
> 
> if x == 0:
>     if y == 0:
>         foo()
> else:
>     z = x + y

Most people don't like the forced indentation in python and I'm one of 
those people.
Enforcing 'prettier' code limits personal styles and makes for a slower 
implementation. No one wants to spend time worrying about how their code 
looks when sometimes they just want to get it done and move on. I doubt 
many bugs would occur from this, unless someone was incredibly messy when 
it came to coding.

The rest of your points I pretty much agree with.



More information about the Digitalmars-d mailing list