• Post Reply Bookmark Topic Watch Topic
  • New Topic

Identifier expected.  RSS feed

 
Harold Lauder
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for the silliest question. I have wrote simple maze but all code written in one class and now I'm trying to re-organize it.
In class Test Var I have x, which symbolize x - coordinate. I want transfer to x to class player, increase it and then take it back. But I have this error:

"TestVar.java:12: error: <identifier>  expected"
How I can fix it?




 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You have to change your Player.moveRight() method to have an int parameter if you want to call it that way. 

That's not the right approach if you're going to write object-oriented code though. A more OO design would be for the Player object to "know" what its x coordinate value is. That means that you will have a private instance variable x in Player and then just have the moveRight() method the way it is.  So basically, the code that's on line 3 right now gets moved down to line 15 and declared as private. Then on line 8, you don't pass x to the moveRight() method. On line 9, you would have to figure out how get to the value of the Person object's x field.  You can do that via a getter method, which you'd have to add to the Player class.

One last note, you don't have to declare the Player class as static. Remove the static word from your Player class declaration.
 
Igor Soudakevitch
Author
Ranch Hand
Posts: 38
7
Android Java Netbeans IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First of all, right now your Player class is top-level --- and top-level classes can't be static. Make Player nested; if you really need it, that is.
Secondly, the method moveRight() in Player doesn't take args --- but you are invoking its overloaded version --- which doesn't exist.

  
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Igor Soudakevitch wrote:First of all, right now your Player class is top-level --- and top-level classes can't be static. Make Player nested; if you really need it, that is.
Secondly, the method moveRight() in palyer doesn't take args --- but you are invoking its overloaded version --- which doesn't exist.

That is incorrect. If you notice the error message, it says "TestVar.java: ..." which means that in this file, the TestVar class is the top level class. The Player class is fine where it is with package-private access. OP should just remove the "static" word from line 14.
 
Harold Lauder
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the advices, Junilu.  Is this correct?



But I cant understand one thing. Should I use setters and getters in this example and how I can use them in right way?

Igor Soudakevitch,
Make Player nested; if you really need it, that is.

Is nested class will help to improve readability more than creating of new class?
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Harold Lauder wrote:Thanks for the advices, Junilu.  Is this correct?


Well.... hint... does the code compile?

Henry
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Harold Lauder wrote:But I cant understand one thing. Should I use setters and getters in this example and how I can use them in right way?

It depends on what the goal of the example is. If you want to see what they can offer, sure, go ahead and add getters and setters. I personally think the class is too small to warrant the use of getters and setters. The reason I suggested what I did was to show you an alternative where encapsulation was used in a better way.  Unfortunately, you seem to have misunderstood what I told you to do. I said you needed to keep the moveRight() method declaration the way you had it originally, where it did NOT take any arguments.  If you declare a method without arguments, then you have to call it without arguments.

Instead of fixing the problem, you just flipped it so that instead of calling a method with an argument when it wasn't declared that way, you flipped it around and called it without an argument when it was declared to need one. Same difference, as they say, and the result is the same: a compile-time error.

The idea was that you just create a new Player object, then call it's moveRight() method without having to tell it anything about the X-coordinate because that's something that a Player object tracks for itself. That's the idea behind encapsulation, to have an internal state that an objects methods will rely on and manage, without exposing any details to anything outside of the object.
 
Igor Soudakevitch
Author
Ranch Hand
Posts: 38
7
Android Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is incorrect. If you notice the error message, it says "TestVar.java: ..." which means that in this file, the TestVar class is the top level class. The Player class is fine where it is with package-private access. OP should just remove the "static" word from line 14.


Mea culpa. I'm awfully sorry. Made a blunder. Player is nested.
Gosh, I need new reading glasses; can't see a darned thing...
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Igor Soudakevitch wrote:Mea culpa. I'm awfully sorry. Made a blunder.

Don't worry about it too much, we've all made mistakes.

Sometimes mistakes can even be helpful in showing other aspects of the problem that might not have gotten as much attention otherwise. Like in this case, the fact that the source file name dictates which class is the top level public class in it was assumed to be known and only called out because of your mistake. I would say that was a "helpful mistake," a mistake that produced a good teaching moment.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:Well.... hint... does the code compile?

Hmmm. Just because code compiles doesn't necessarily mean that it's correct.
But I certainly agree that it's a good place to start.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!