Liutauras Vilda

Think of it that you don't implement methods inside interfaces. Interfaces provide, well, an interface, while the actual implementation reside in the implementing classes, similarly as I showed you in the examples. Did you analyse them carefully?

Alright, since you write/have an interface which has few methods defined in it, one of which is isAbleToFly(), the implementing class should return true or false based on some of its properties or simply knowledge of the thing it represents.

One note, Launchable interface name is poor for what methods it contains. Look down below how that reads (example 1). Other examples demonstrate possible implementations.

example 1:
public final class Eagle implements Launchable {    @Override    public boolean isAbleToFly() {        return true;    }     ... }
example 2:
public final class Car implements Launchable {    @Override    public boolean isAbleToFly() {        return false;    }     ... }
example 3:
public final class Plane implements Launchable {    private double amountOfFuel = ...    @Override    public boolean isAbleToFly() {        return amountOfFuel > 0;    }     ... }

would the rest just be:

return true;
{
else
}
return false;

And what condition(s) would cause you to make one or another decision? (to return true or false)

Congratulations to all the winners. Have a great read.

Thanks to authors.

Dan Red wrote:first > second
return  first

should be

first > second
return second

My brains working harder than they should in order to understand how you said it "should be".

I'd expect it to be:
if first <= second   return first else   return second
One would think not a big difference, well, for me it is.

Also I've added <=, I find it easier to understand that way. I'd expect that majority would find it easier that way, simply because looking to "if" part one could identify in case of equal values what value would be returned without even looking how "else" part is implemented.

Hi Siegfried,

Thanks for raised concern. I've split your post from the main topic because this post has little to do with what OP was asking.

I know how it may seem to you Campbell's response, however, I don't think it was meant in the way how you actually read/interpreted it. That's what Internet layer shadows - an actual intended emotion of the post.

Now, why I'm so confident in saying this, that's because I know Campbell to some good extent, while you, and possibly OP doesn't. I'd agree with you, that sometimes we moderators over the countless years of participation in these forums forget, that other members may not know us well as we know each other as members of staff, so they may imply our intent of emotion differently. But hey, how do you know OP read Campbell's reply in the way you read it?

I have been a student myself, and we see quite a lot students on daily basis here on these forums coming with the questions/problems they are potentially struggling to tackle - so we (as a staff) and all community in general trying to help them. Now, we saw these type of posts many times, and the rest assured, we are going to see them again - it is a classical example with the programmer falling into the trap of starting to code right away without taking an advantage to understand the problem really well at first.

In my opinion what Campbell provided as his response is essentially the same as we do provide as a response more often than not to all other questions of the same kind, in other words - "to go back to the drawing board". And I personally didn't see it as a bad response. Isn't it nice to read responses which aren't templates but rather with some slight irony to help OP to understand, that really need to re-consider the taken approach - don't forget, that programmers also usually have a good sense of humour - so no offense here really.

I apologise on behalf of the staff if our response looked harsh to you, but you can be assured - that wasn't an intention.

On the other hand, there are more members of staff, and if somebody would feel that response is indeed on the borderline of being "not nice", it would be asked to be re-worded - it didn't happen that yet, at least not from my side.

Welcome to the Ranch once again. Have a great week and perhaps one or two few tricky questions

Alright, so what I was writing it was different thing, still valid though.

However, what Campbell gave as an example he was right I think demonstrating that it actually works. And so Jeanne added to errata.
I personally know little about Java 11 features, about this in particular I heard, but never tried myself, so can't comment much on that.

But now that you explained all the story in more details, somebody might will expand more on this.

What's regarding source code filenames and class definitions there are 2 (at least) things to understand.

If the top-level class in the source code is defined as public, class name MUST match the filename it is defined at (Something.java). That suggests one thing right away - you can have defined at most 1 top-level public class within singular source code file as well as you can have optional non public top-level classes.

If the top-level class in the source code isn't public (meaning it is package private, because top-level class can have either public or default visibility only), filename of the source code and the class name can be different, and same as above, you can have them multiple defined.

Dinkar Joshi wrote:I am using Java 11, and just read in a book, that Single File Source code you cannot use this new feature for a single-file. program with two classes in it
Single File Source Code: I am able to have more than 1 class in the same file, yet the program runs.
Can  anyone explain? Help?

For current and future readers, do you mind giving an example what do you mean? I don't understand to be honest.

Campbell's example is good, but you say he misunderstood you... Can you please explain with an example what book says you cannot while you actually can.

Stephan van Hulst wrote:So making commits in a detached HEAD state is useful when you want to experiment a little and then 'throw away' your work when you switch back to a real branch. It's not advisable to perform experiments this way though.

Agree it is not advisable to commit code which is not being tracked by the branch. The main reason for that is, that commits which aren't tracked by the branch may be garbage collected. So if you checkout to a branch and after an X amount of time wnat to get back to your untracked commit - it may be gone already. Similarly as in Java, they are marked as eligible to be garbage collected, but you don't know when it will happen.

As Stephan said. If you want to experiment with some code from the past - [1] checkout the commit you are interested to base your experimental development on; [2] create branch (being at that commit); and that way you are safe to go.

I too recommend to do Git related work from the command line while you learning it. That is an IDE agnostic way of having an understanding of it. In the future you'll reach the point where you may want to do that with an IDE, because I think you can be more productive with it.

S Fox wrote:i wrote my statements as "if (x)" until i saw that the ranch style guide advised not to do that.

ranch style guide:
if (oatmeal == tasty) else if (oatmeal == yak) if (superHero == theTick) if ( (hero == theTick) && isTickSidekick )

Could you please give a link to that? I’d like to believe that it is not like you are saying. And still believing.

Campbell Ritchie wrote:"Posts: 66666"... It would make my post count look even worse than it really is.

It will look worse when you actually make them upside down. You may need some extra tricks than those we saw in the past as singular "... and welcome..."  

Other than that, sorry for being so rude not congratulating at first. Congratulations