On Thu, Jun 19, 2014 at 10:03 AM, Pat Ferrel <[email protected]> wrote:
>
> but as I read the Scala style guide it should use infix notation like this
>
> val columnIDs = interactions map ({ case (_, columnID) => columnID})
> distinct() collect()
>
Well they are supposed to be an authoritative source on this so they are
correct by definition.
But this style has complication.
(1) First, if you want to have a readable code with comments, and explain
absolutely everything you do, like i prefer to do it, it is easy to see
that infix notation simply doesn't compile:
val columnIDs = interactions
// I want to run some map here
.map ({ case (_, columnID) => columnID})
// I want to do distinct here
.distinct()
// I want to collect here
.collect()
So i am forced to use dots before "map" etc here. Which is what i do.
(2) Once i started using dots, there's usually no way to mix in infix later
even if i wanted to put on the same line, so i use dot again :
val columnIDs = interactions
// I want to run some map here
.map ({ case (_, columnID) => columnID}) distinct() // syntax error
So too many exception to infix style, i dropped it except for where i have
a clear operator like A * B
(3) keep working . Usually ( is not needed if { is also used
val columnIDs = interactions
// I want to run some map here
.map {
case (_, columnID) => columnID
}
// I want to do distinct here
.distinct()
// I want to collect here
.collect()
(4) I usually avoid placeholders, i.e. i'd rather write
interactions
.map { p =>
p.value
}
than
interactions
.map(_.value)
(5) Incidentally, partially defined function in this example used to
disassble structure into explicitly named components. It is not what
partially defined function was created for, and it can cause
NoMatchException (or whatever its name), but it turns incredibly useful for
disassembling values. Hence prefrered style for e.g. mapBlock notation
drmA.mapBlock() {
case (keys, block => .
...
}
(5) I think Spark presentation didn't use infix notation even in single
line,
Either way, over the years i have strongly adopted at least throughly
commented step-by-step style as in (1) and explicit parameter naming
(albeit at cost of a partially defined function) as in (4) and (5). I still
sometimes slip on other points.
