On 2013-02-26 22:26, H. S. Teoh wrote:
I find the Phobos version more readable, actually. Writing "2.days.ago"
is all neat and clever and everything, but the logician in me protests
at what all those '.'s are referring to, and they do. Code is not
English, and when it pretends to be English, it makes me suspicious that
something is subtle going on that I'm not aware of. And when I'm coding,
that's something I don't like -- I need to have the assurance I know
exactly what's going on. And yes I can learn to parse "2.days.ago"
eventually, but it's just additional mental load for only superficial
convenience.
I don't agree. BTW, the whole point of having programming languages is
for programmers to read and write it. Therefore they are similar to
English (or some other language). For the computer the language is just
in the way. It just wants to execute machine code.
IMHO this is just bikeshedding. I actually find Phobos' order more
intuitive (to me anyway), because the function you're reducing on,
ideally, should be inlined, so it makes sense to pass it as a
compile-time parameter, and the seed value is what you start with, so it
makes sense to have it appear as the first parameter.
I never said it shouldn't be passed as a compile time parameter. Look at
the example. I added the seed to the compile time parameter list.
But I can see where UFCS will fail to kick in here, which makes it a bit
annoying, I suppose. But reduce was designed before UFCS made it into
DMD.
Then it should be changed. Oh, wait. We can't break any code, every
I don't know why I keep bothering. You (not as in "you" personally)
never want to improve anything.
Couldn't you use map for this purpose?
No, not as far as I know. "map" expects a range and returns a new range.
"tap" expects an object and returns the same object. You can use "tap"
to tap into chains of method calls and change an object.
Unfortunately, on this point I have to disagree.
I find !isBlank much better. Generally, I prefer a more minimal API, but
I suppose people coming from Ruby might expect a more "rich" kind of API
design (caveat: I don't know Ruby). Having too many ways of stating the
same thing makes me wonder if there's some subtle bug lurking somewhere.
What if isPresent is not 100% equivalent to !isBlank? And I don't mean
just hypothetically; I've seen cases of libraries where bugs cause two
supposedly-opposite functions to be not exactly opposite, and then code
starts to depend on the buggy behaviour, causing hidden bugs later when
the code gets fixed, etc.. A lot of unnecessary problems when you could
have just written !isBlank in the first place.
This is not about adding "isPresent" to an already existing "isBlank"
this is about adding "isBlank" or "isPresent" which don't exist.
Now, I used to be a Perl fanatic, so I totally understand TIMTOWTDI and
all that, but I think having a separate function just to encode !isBlank
is a bit too extreme. The language has boolean operators for a reason,
after all.
isBlank does way more than checking if a value is false or not. Do you
read the code at all?
--
/Jacob Carlborg
