@mfikes the truth is, I've been lying to you this whole time. native-image just spins up your CPUs and stores the cycles. Later when the output of native-image is running that CPU power is slowly released to improve the overall performance of your program.

Hah! So that's how the magic works.

how do I connect my bikes to my CPUs to help native-image store cycles faster.

that's --hansnfranz

Damn. This reminds me of compiling the Linux kernel in 1994.

1. I do a deftype / defrecord, and create some objects. Call them OLD objects. 2. I modify some member function of a deftype/defrecord, of some protocol. 3. Now, is there anyway to get all the "OLD OBJECTS" to promote to the new member functions ?

no

defmulti/defmethod won't have this problem right?

correct, because there you deal with the ILookup / keyword abstraction found in defrecords

defmulti prevents reloading, but defmethod avoids the problem - if you need to redefine defmulti's dispatch that can lead to odd things though

which will work anywhere else, code against defrecord with (:kw record) vs (.-kw record) and it will work fine

(defn real-foo [obj] ...) (deftype Foo IFoo (foo [this] (real-foo this))) would solve the problem right?

as I can redefine real-foo, and "foo" will end up calling the reloaded real-foo

I guess? but in that case, why use deftype in the first place?

I like deftype to (1) specify which protocols it satisfies and (2) make explicit the members (instead of adhoc maps)

a good rule of thumb: stick with multi methods and maps until you benchmark a working app and see them to be too slow

I'm not trying to do this for performance reasons. I find that defprotocol helps with abstration and deftype makes it explicit what the members are. With a map I'm always guessing "what keys should this have"

re: graal and native image, I hope someone will come up with a leiningen plugin for that

When m is a map and :key is a keyword, you can do either (:key m) or (m :key) — is there a practical difference or does it come down to style? Is there a preferred form?

(:key m) is preferred.

Thanks — any rationale behind it? I get that doing (:key m) makes it immediately obvious that m is a map, whereas (m :key) could be any function call, esp. if the map is named something more descriptive.

The main difference is that if m is nil, (m :key) will throw whereas (:key m) won't

That goes both ways too ofc 🙂

Also, I see (get m k) if k is a variable/string, more than I see (m k).

@cryan Normally you'd fully qualify the symbol, using the help of syntax quote:

(spec/exercise-fn `zipcode-or-place)

@mfikes yeah, if i manually type out the fully qualified symbol, it works, but for some reason when i call it with the backtick, i get the error.

Hrm. The above works for me.

hmmmm the hunt for what weird thing am I doing.

You need to be in that namespace. Try evaluating

`zipcode-or-place

Ahh, that's not a backtick.

oooh

`

Right 🙂

thanks 🙂

🙂