On Dec 20, 3:17 am, Reinier Zwitserloot <[email protected]> wrote:
> Except 'length' is much more descriptive, and /: and \: are aliases
> for foldLeft / foldRight (a more appropriate simile would be that
Yes, but your objection was that you couldn't avoid /: and :\ because
they were "always there." My counter is that they are not "always
there" they are properly namespaced in List. If your team doesn't
like them then it can simply not use them - and enforce the rule with
the standard tools that all programming teams use to enforce
consistency in their code bases (coding standards, code reviews,
pairing, automated code checkers, etc.). Every Java team I've ever
worked with has had a list a mile long of constructs they prefer to
avoid.
> making code 'easier to read', which I think we can all agree is not
> really a good strategy to get there.
Sure we can, but we can disagree on strategy. I honestly think
that /: and :\ are more readable once you learn them. On the other
hand, if you don't know foldLeft and foldRight then they are complete
mystery in spite of their English looking names. The only advantage
foldX has is that it's easier to look up in Google. But as I said,
teams are free to disagree with that preference.
> it. In scala you've got a bazillion ways to foldLeft. The dots are
> optional, they can bind to either side (/: hangs right, :\ hangs
That's how you can write "a + b" instead of "a.+(b)". It's a
consistent rule regardless of these particular methods. Same deal
with hanging things of the left and right. The colon rule is why you
can write head::tail to prepend something to a list. These are rules
to support readability.
> No; you don't program in a vacuum. You use libraries. It'd be kind of
> a drag if an enterprise shop decides: You can't use libraries that use
> any implicit def in its API, because we abhor implicits in general.
I didn't say don't use libraries. I said import just what you want
and supply implicit parameters explicitly.
>
> Look a little closer. There isn't an easy fix for this, other than
> using an scala.lang level implicit
What? You listed the easy fix as option 1 on your bug report. No
need for implicits. There's also the ever so slightly harder fix of
getting rid of the type alias and just using => Unit. It is annoying
that you can't alias by name types, yet, but again the error message
is pretty clear if you try.
> really isn't all that helpful in fully understanding why () => FOO is
> somehow different from => FOO / named parameters.
No compiler explains all of a language's semantics in its error
messages. That would be irritating. If you make mistakes in Java
regarding the proper use of static vs non-static inner classes, you
don't get a complete lecture on the differences and tradeoffs. You
get just enough information to either fix the problem if you already
understand the differences or go look up the differences if you don't
know them.
Anyway, back to this problem, since a new user can visually see that
"() => FOO" is different from "=> FOO" and the compiler is saying that
it's a type mismatch then he or she is already armed with enough
information to look up the difference if it's still unclear. But be
that as it may, it's still nothing with a cascade of possible errors.
Like many type problems it has two possible fix locations: the caller
and the callee.
> I'm not willing, for the sake of this argument, to spend a day creating the
> particular mix of methods and code again to give you the compiler errors.
And there's where we hit a wall. The readers of your post have no
idea how to judge the veracity of your claims. The Scala team can't
improve it if it's a real problem. Instead it's all just vague "it's
so complex you need an A.I. in the compiler" claims. All I can do is
offer a counter claim, also with no evidence, that I've never been
confused by the error message caused when I flip the arguments to
folds.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
