All Java Collections Framework classes are implemented modulo Object.equals.

Our visitors are also not a performance bottleneck right now so while I
will compare performance before and after, I don't anticipate a problem at
this time, which means we can optimize as the need arises. Also it's worth
noting only BasicVisitor overrides cache to true, because only that class
did that check in the original implementation I am erasing. So this isn't
doing anything that wasn't already being done.
On Apr 11, 2014 3:34 PM, "mdmkolbe" <notifications@github.com> wrote:

> In
> src/javasources/KTool/src/org/kframework/kil/visitors/AbstractVisitor.java:
>
> > + * To use this class as a transformer, see {@link BasicTransformer}.
> > + * @author dwightguth
> > + *
> > + * @param <P> The parameter to pass to each visit method. Use {@link Void} if not needed, and call
> > + * {@link ASTNode#accept(Visitor)}.
> > + * @param <R> The parameter to return from each visit method. Use {@link Void} if not needed, and
> > + * return {@code null}.
> > + */
> > +public abstract class AbstractVisitor<P, R> implements Visitor<P, R> {
> > +    protected org.kframework.kil.loader.Context context;
> > +    protected KompileOptions kompileOptions;
> > +    protected GlobalOptions globalOptions;
> > +    protected ExperimentalParserOptions experimentalParserOptions;
> > +    String name;
> > +
> > +    protected java.util.Map<ASTNode, R> cache = new HashMap<>();
>
> Note that this cache is very inefficient until hashCode() is better
> implemented.
>
> Something that didn't occur to me when I talked to Dwight yesterday is
> that even with a fast hashCode() this HashMap might be slow if HashMap uses
> Object.equals instead of pointer equality. I can't find anywhere that the
> JavaDoc says one way or the other.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/kframework/k/pull/364/files#r11550648>
> .
>