Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation and Specification difference in getPlayer(int x) method of ConnectFourGame. #344

Open
ashishrana160796 opened this issue Feb 21, 2018 · 4 comments

Comments

@ashishrana160796
Copy link

Documentation differs from implementation as nowhere it is specified that this method returns null if playerNum doesn't match the case value. Which will also lead to the following method being affected also :

@Override
	public String getPlayer(ConnectFourState state) {
		return getPlayer(state.getPlayerToMove());
	}

Referred snippet of code in this issue:

/**
	 * Returns the player corresponding to the specified player number. For
	 * efficiency reasons, <code>ConnectFourState</code>s use numbers
	 * instead of strings to identify players.
	 */
	public String getPlayer(int playerNum) {
		switch (playerNum) {
		case 1:
			return players[0];
		case 2:
			return players[1];
		}
		return null;
	}
@roychowdhuryrohit-dev
Copy link

Adding a @nullable annotation can solve this issue.

@ashishrana160796
Copy link
Author

ashishrana160796 commented Feb 22, 2018

@roychowdhuryrohit-dev considering your point of @Nullable annotation addition makes the method String getPlayer(ConnectFourState state) {...} of same return type. Which is quite wrong as the method it is overriding from is of @nonnull return type method in aima.core.search.adversarial.Game. Here is the following error message :

error: [override.return.invalid] Incompatible return type.
	public @Nullable String getPlayer(ConnectFourState state) {

The issue of ambiguity in specification is substantiated with is illustration. Sure, specification doesn't forbid null value type in return. But it is expected to return some value when called, which is inferred from it's usage in code.

@hriaz17
Copy link

hriaz17 commented Mar 1, 2018

I am going to try to fix this issue. - GSoC

@hriaz17
Copy link

hriaz17 commented Mar 5, 2018

Would adding @nullable annotation before the getPlayer(STATE state) method in the game interface resolve such an ambiguity? @norvig @ctjoreilly @ashishrana160796?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants