"What's really cool about this in Java is that you don't have to catch that mistake. It won't compile."

Oddly, I was just bitten today by a language that doesn't catch it at compile time. I added a few functions to my PL/SQL package on Tuesday 5 minutes before leaving. I forgot to put in the return statement to the functions - stupid mistake caused by rushing. It compiled fine but today I had a heck of a time debugging odd run-time behavior. I would have thought that checks for a return would be compile time given PL/SQL's ancestry being Ada and Ada's safety record.

Anyway, it makes me appreciate languages like Java that do perform the check a compile time.

> > Since when has the approach of setting a boolean
> variable
> > inside a loop been considered terrible style? I'd just
> > call it an imperative style. That's how I was taught to
> > program in C, and how I continued to program in C++,
> and
> > how I programmed in Java. I did this for years and
> years.
> > When looking for something in a collection I'd
> initialize
> > a boolean variable named found to false, then set it to
> > true inside the loop. I wasn't clued into making little
> > functions so I could avoid mutable variables like
> you've
> > shown in your example until I was faced with val versus
> > var in Scala. Trying to figure out how to get rid of
> vars,
> > and puzzling over why I would care to to do that, is
> where
> > I got the insight into how the functional style could
> make
> > my code better.
> >
> > Do many people already try and avoid mutable variables
> > like this in Java?
>
> OK you've got me. I'm really only speaking for myself
> here. There's no consensus (that I see) that this is bad
> style. But I have specific reasons for why I believe it
> to be so and the reasons I've often heard for contrary
> usually amounts to what you provide: "That's how I was
> taught to program in <language X>"
>
> What you did here is not the worst case of this but it's a
> general problem I see in Java: extraneous variables,
> usually boolean flags. It actually makes sense in a some
> languages specifically those that do not guarantee all
> branches of a method return a value or that variables are
> assigned before they are used.
>
> Generally I see things like this:
>

> int getFoo(int in)
> {
>    int out = 0;
> 
>    switch (in) {
>      case 1:
>        out = 10;
>        break;
>      case 2:
>        out = 200;
>        break;
>      case 3:
>        out = 15;
>        break;
>    }
> 
>    return out;
> }

>
> This is then declared to be "good practice" because you
> know what getFoo returns: the value of 'out'. This to me
> is a 'turtles all the way down' kind of argument. Knowing
> the name of the variable that is returned at the end of
> the method is not important.
>
> Consider the alternative style:
>

> int getFoo(int in)
> {
>    switch (in) {
>      case 1:
>        return 10;
>      case 2:
>        return 200;
>      case 3:
>        return 15;
>    }
> }

>
> Much simpler and if I ask you what it returns it returns
> 10 if in is 1, 200 if in is 2 and 15 if in is 3 and... Did
> you catch it? This doesn't return anything if something
> other than 1, 2 or 3 is provided. What's really cool
> about this in Java is that you don't have to catch that
> mistake. It won't compile. So if I'm coding on the tail
> end of a bender, I just saved myself some frustration. It
> might also make me realize that I don't want to return 0
> for all other cases. I might want to do something else if
> a negative number was passed in.
>
> In fact, I actually sometimes write code like you have
> done here, although it's usually out of laziness and flags
> are sometimes the right choice. The point I'm trying to
> make is that by switching to an unfamiliar paradigm you
> are able to lose a lot of baggage that you've accumulated
> that may not have anything to do with Java at all.
>
> I actually completely agree with your overall premise here
> but it might seem like you set up a straw-man a bit (which
> I don't think was your intention.)
>
Sorry if I unintentionally strawed you. I just was curious if I had missed the Java community talking about this kind of thing. I need to look at the latest Effective Java again for this, because that's pretty influential on how people code, I'd expect.

It looks to me like you have subconscious functional urges trying to manifest themselves in your Java style. Bill Pyne made a good point about using the variables to look at intermediate values in debuggers. I also like to put intermediate values in variables in complex expressions just to give them a name to kind of explain what I'm calculating, just for code readability. But it also can help when debugging I think.

I also was told by someone at some point, maybe back in my C days, that it is better to just have one return statement in a function or method. But I was also told by others that they liked multiple returns to keep the method less nested. I think I usually leaned towards trying to just have one exit point, but I remember not being sure it was the best way.

Anyway, Java's switch statement is an example of how Java kind of pushes its users towards the imperative style. It is an imperative control construct because it doesn't result in a value. Java's equivalent construct, match, can do the same kind of thing. For example, I could say in Scala:

def getFoo(in: Int): Int = {
  in match {
    case 1 =>          
      return 10;
    case 2 => 
      return 200;
    case 3 =>
      return 15;
  }
}

But match is a functional control construct because it results in a value. The value it results in in the previous example is called "Unit", which is a bit like void. But I could simply make it result in an Int like this:

def getFoo(in: Int) = 
  in match {
    case 1 => 10
    case 2 => 200
    case 3 => 15
    case _ => -1
  }

The case _ at the end is a default case, like default in Java switch statements. Scala's match doesn't fall through, either, so you don't need break, and in fact Scala doesn't even have break. The result of this match expression will either be 10, 200, 15, or -1, and because it is the last expression of the method, that value will be returned. No explicit return is needed. When I look at your examples, I get the feeling you're wanting to do this kind of thing in Java, but that Java doesn't make it as easy as Scala. The other thing you did in your previous post was make a little function, which is something I do a lot more in Scala than I did in Java, because Scala encourages that style with its concise syntax for functions and support for local functions (which are functions declared inside other functions, and only available in that scope).

>
> I'm with you on this Bill. I was taught to set the
> variable so you could see the return variable's value in
> dbx before the return.
>

We could do with debuggers that show a functions return value without needing artificial variables.

> I'm with you on this Bill. I was taught to set the
> variable so you could see the return variable's value in
> dbx before the return.

I think that's the point. The variable only exists for the potential benefit of using a debugger if you have to step through the code. Apart from that, it's existence adds nothing to the method and it could be replaced by a return statement because the return value has been calculated, so there is no longer any reason to remain in the method.

(Overall though, it's just a minor distraction since the point of the article was to demonstrate Scala capabilities not Java coding style artifacts.)

In a pure function you need only verify that the valuye returned by each return is sensible. With a method evaluated for its side effects you have also to verify that all the required side effects have been produced in preceding code. You might modify such a method and fail to notice that an earlier return takes place without causing your modifed side effect to take place.

> Less OO, which normally I'd complain about, but, IMO way
> clearer, and I was never that fond of the underline.
>
The underscore is an optional placeholder syntax. Other possibilities, in increasing order of verbosity, are:

name.exists(x => x.isUpperCase)

name.exists((x) => x.isUpperCase)

name.exists((x: Char) => x.isUpperCase)

But if someone else uses an underscore and you're reading your code, you'll have to look at it. It can be a cryptic if not used well, but if used well it reduces a bit of boilerplate.

> Less OO, which normally I'd complain about, but, IMO way
> clearer, and I was never that fond of the underline.

I not big on the underline either. It seems too Perl-esque to me. I mean, why underline, why not implicit variables?

One the other hand, as long as it's consistent and there aren't too many other 'things to know' to use Scala, I'm OK with it.

On a side note, the python for comprehension syntax is nice, IMO:

[x.foo() for x in list]

> > This is exactly the benefit that I've found to prefer
> > Lastly, the irony I see in the multi-return style
> you're
> > recommending James is that you're doing it to get
> benefits
> > you get if the language would let you more easily
> program
> > in a functional style. Java just makes it hard because
> so
> > many of its control constructs don't result in a value.
> > When everything results in a value, it is easier to see
> > each function as just one expression, which results in
> a
> > value. You don't need an explicit return, because that
> > last value is returned implicitly. But that's the same
> as
> > having "one return" in the method.
>
> I think you are misinterpreting my argument. My point was
> never to demonstrate that Scala isn't an improvement over
> Java. I think it definitely has a lot to offer and that
> Java has many flaws. My point was that the comparison you
> showed was a little unfair, kind of like a car race where
> one car has bags of concrete in the trunk. Scala still
> wins IMO and making Java look worse than it really is
> might make your argument appear weaker.
>
Oh, I was trying to be fair to Java. That's why I showed that Java can actually do it in one line. Had I thought of the foreach approach that Dave B showed, I would have showed that too. I have tried hard not to try and push Scala up by putting other languages, especially Java, down. Instead, I try and show the differences and talk about the plusses and minusses of both.

I'm not sure why you thought I was suggesting you were trying to say Scala isn't an improvement over Java. I didn't get that impression. The "irony" I saw was that to get at the benefits of the functional style in Java, Java syntax actually pushed you in the other direction.

As far as using the boolean variable, that's not me being unfair to Java. That's me being true to how I programmed in Java for 10 years, and how I think most people program in Java from the code I've seen over the years. That's the idiom, and returning from inside a for loop, which you showed, would I think be frowned upon by many Java programmers.

> Basically, we have these rules that we follow in Java
> "because they are good" and we complain about the
> resulting code. Then we take a new language and declare
> those rules don't apply in it. But really, a lot of those
> rules never really applied in Java either. Bringing these
> kinds of things into the comparison is just noise and
> makes it harder to see the real differences.
>
Which rules to you mean? Sorry, can you be more explicit? If you mean he rule of having just one return, that doesn't quit add up because in Scala that's also the rule of thumb, except that you see it as one expression that doesn't need an explicit return.