Skip to content

Provide a way to workaround equality semantics for NotAtoms #126

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

Open
skapral opened this issue Jan 27, 2018 · 0 comments
Open

Provide a way to workaround equality semantics for NotAtoms #126

skapral opened this issue Jan 27, 2018 · 0 comments
Assignees

Comments

@skapral
Copy link
Member

skapral commented Jan 27, 2018

Currently, equality semantics for Atoms is defined in this way:

  1. Atom-typed fields are always compared by equals
  2. NotAtom-typed fields are compared by reference, if indeed referenced to NotAtoms

However, in some rare cases, comparison of NonAtoms by reference may be inconvenient for some types. Consider this class:

@NotAtom
class CachedScanner {
    private final String string;
    private Scanner scanner;

    public CachedScanner(final String string) {
        this.string = string;
    }

    public final synchronized Scanner getOrProduceScanner() {
        if(scanner == null) {
            scanner = new Scanner(
                new ByteArrayInputStream(string.getBytes())
            );
        }
        return scanner;
    }

    @Override
    public boolean equals(final Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        final CachedScanner that = (CachedScanner) o;

        return string != null ? string.equals(that.string) : that.string == null;
    }

    @Override
    public int hashCode() {
        return string != null ? string.hashCode() : 0;
    }
}

It is mutable, so it is not Atom. However, it clearly defines equality logic, and equality logic is not tied to mutable state, so it is rather safe to rely on it. The task is to give developer the possibility to specify such exclusions from the rule.

@skapral skapral self-assigned this Jan 27, 2018
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

1 participant