Skip to content

Provide a way to workaround equality semantics for NotAtoms #126

@skapral

Description

@skapral

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions