> Then deftype is out of the question because it can't extend classes, only implement interfaces But you can extend all the right interfaces to introduce map semantics. There's no real need for inheriting classes here. In fact, it's actually better if your fields are proper members of T. If I'm not mistaken, that's exactly how records achieve map semantics.

So you're saying I should basically re-implement clojure.lang.PersistentHashMap? Sure I could, but that'd be pretty much the opposite of sustainable software engineering.

typically in this case you would implement IPersistentMap, not extend PHM

and you can, for example, hold a map as a field and defer most calls to that

yeah, delegating to PHM would certainly be better, but still it increases the maintenance burden if e.g. clojure's relevant interfaces & implementations change.

Not likely that it would, given its history and Clojure’s commitment to not breaking existing things: https://github.com/clojure/clojure/commits/master/src/jvm/clojure/lang/PersistentHashMap.java

This sounds like a great use case for metadata

metadata is defined with the caveat that it doesn't affect equality, so seems like a terrible use case for that

“terrible”, yikes. Or maybe I simply misread the comment after > That is, it has some field x in T that is irrelevant to its identity, so (= a b) for a, b instanceof T should disregard the values of x in a and b. If I’m reading and didn’t see that he wants :x to work as an accessor etc

making this easy is a non-goal - you are strongly encouraged to use the built-in collection types and value equality semantics. if you want something else, that's possible but the burden is on you. there are some libraries like Potemkin that have helpers for creating custom map-like structures

> making this easy is a non-goal - you are strongly encouraged to use the built-in collection types and value equality semantics. if you want something else, that's possible but the burden is on you. Yup, that was my vague impression as well: It's just not a design goal of the language, also due to its heritage. But I'll definitely take a look at potemkin, thanks for the pointer 👍

@U02PSA71D0E what about metadata? You can store fields that don't contribute to equality semantics in the metadata map, and most operations preserve metadata.

It may not work for you, but it may be easier than implementing your own persistent map

I see that suggestion was already discussed.

Hm... making the "irrelevant" fields metadata so they don't contribute to the map's identity... @U064X3EF3 said it's a bad idea, but maybe he interpreted the suggestion differently...? The way you put it, it definitely sounds very interesting.

yeah, if you are just "adding" non-data then metadata is a good use case for that

maybe I was too into the original description

That sounds very much like the "other way" I was overlooking 😁

Hey @U02PSA71D0E , it seems maybe you’ve got your answer for “how”. But I’m curious about the “why”. What kind of structure do you have where equality needs to ignore a field? Could that be modeled as two separate entities? Like you have a and b, and others like them stashed somewhere, and then some other structure holds a map of a to a’s value for :x, and b mapped to b’s value of :x . I’m trying to imagine the scenario you’ve described. More details, please.

I'd rather write a separate T= function, so as not to break existing language semantics. I.e. Don't make equality checks pass, because they're not equal. Rather introduce the new notion of equality, separately.

Maybe https://github.com/PEZ/pirate-lang can be useful here. Although I'm not sure why the REPL functionality has to be online for a technical interview.

It should be in $JAVA_HOME/lib

what are you grabbing from tools.jar?

I need com.sun.tools.attach.VirtualMachine and maybe a couple of other things I haven't discovered yet.

Last time I looked into it, it was available in <jdk home>/lib directory (not jre).

Thanks @U42REFCKA and @U3MRWH35M. It looks like URLClassLoader will do the trick if the jar can be found at that location, right?

One issue I ran into was that the jdk version for tools.jar had to match the jre version it is running for, IIRC.

It would be interesting to hear what exactly are you doing with the tool/library. Perhaps there are existing tools that can solve your problem immediately?

I am attaching an instrumentation agent to the current JVM process. Essentially the same thing done for the "ouroboros" agent of https://github.com/HCADatalab/powderkeg. (https://www.youtube.com/watch?v=OxUHgP4Ox5Q) Then I am using the agent to write class files for all of the in-memory classes created by the Clojure compiler at runtime. The purpose is for distributing work to a remote JVM.

https://github.com/pallet/lein-jdk-tools does exactly this https://github.com/clojure-emacs/enrich-classpath also does it, but also does quite a lot more :) so could be only serve as inspiration (I don't remember if there's any substantial difference between most impls. Most likely not)