<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
</span>I don't even like the idea of using maps for this, but the "old<br>
fashioned" tuple type seems to be discouraged in the R18 docs. Meh.<br>
<br>
So much for trying to be hip to the new thing. I like my old tuples.<br>
I don't think there is anything in here that doesn't work even with<br>
rather old ERTS releases, so I'm switching this (back) to tuples.<br>
With regard to tuples VS maps for trivial things like this... I almost<br>
feel like its a case of getting a newfangled toy and simply feeling<br>
compelled to use it everywhere.<br></blockquote><div><br><br></div><div>As someone with less than 10,000 hours of OTP code under my belt, I found this change (tuples to maps) to be so useful that I immediately upgraded all my code to require version 18.<br></div><div>With the tuples, I had to check the documentation every single time I made a supervisor to confirm whether it was `intensity` or `period` first. I also would get copy/paste errors because I'd copy the child spec for a worker that was set to `brutal_kill` and use that as template for a supervisor without changing it to `infinity`.<br></div><div>The new maps are self-documenting and they provide sane defaults so that if I want a vanilla supervisor I can just say `#{id => cool_super, start => {M, F, A}, type => supervisor}`.  Not only do I avoid dumb bugs, but it's also clear that this is a vanilla supervisor and not something more interesting.<br><br></div><div>It seems like a small change, but I thought the old tuples were _awful_ and I was very happy to see them marked as deprecated.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> Oh, a layout issue.  I don't like big black blobs (except when I<br>
> write them).  So<br>
> %% wdrwertwertwert<br>
> %% wertwertwertwrt<br>
> %% wretertwertwertew<br>
> -spec frgsdfgdfghsdfg<br>
> asdfasdf(sdfgsdfg) -><br>
>     ....<br>
><br>
> is just a bit too much for me to be comfortable with.  I'd find<br>
> it easier to read with blank line after the %% comment block<br>
> and a blank line after the -spec.<br>
><br>
> I find that with my OWN code it's so obvious that packing it<br>
> tightly doesn't impair readability, but with someone else's<br>
> code well-placed blank lines never go amiss.  I can only suppose<br>
> that I'm in error about my own code and that it too could do with<br>
> more blank lines.<br>
<br>
</span>*MY* code is always perfectly readable as big, immaculate, unbroken<br>
blocks. Until a few months later. Ugh.<br>
<br>
I'm not sure where I stand on the line break issue, really, but since<br>
you mentioned it I'm trying out a line between doc and spec, a line<br>
between spec and definition, and two lines between functions (but no<br>
lines between function clauses -- I already know that confuses me,<br>
especially with un-specced/un-docced functions).<br></blockquote><div><br><br></div><div>I don't feel very strongly on this one (I do about the supervisor spec), but I find the tight-packed blocks _more_ readable in other people's code. I run my eyes down the left-hand side and see<br><br>%<br>-<br></div><div>a<br></div><div><br></div><div>And that's pretty clearly (1) some comments, (2) a compiler directive, (3) a function. They all go together: I expect the comment to be function documentation and the dash to be a function spec.<br><br></div><div>If I see<br><br>%<br><br>-<br><br></div><div>a<br></div><div><br></div><div>Then the comments might be module-level comments and the directive might be an export or an if or a define or a type declaration and I have to read more characters to figure out if those three lines are related.<br></div></div></div></div>