Fork me on GitHub
Drew Verlee01:04:06

@noisesmith Yep, fantastic. Thanks for the example

Drew Verlee01:04:25

Is it still the case that Java doesn’t have any way to extend an existing class?

Drew Verlee01:04:33

I can google this..


right - we can't really expect that to change


with protocols, we can extend the protocol from outside the class


I’m working in ClojureScript. I’m unable to call a few core functions [`get` keys] due to TypeError: not a function problems.


here’s the trace for keys Uncaught TypeError: coll.cljs$core$ISeqable$_seq$arity$1 is not a function at Object.cljs$core$seq [as seq] (core.cljs:1125) at cljs$core$keys (core.cljs:8331)


wow, that's odd, my first instinct there would be bad caching, second instinct would be a namespace so broken that you get undefined behavior


if it's bad caching and you are using lein, lein clean would fix it


I deleted the build dirs, still happening.


@drewverlee one valid way to interpret "any way to extend an existing class" is to make it a question about inheritance (which is how you extend things in java), but we use String directly for string literals (I guess an implementation decision could have been made to implement an alternate CharSequence that was also callable but that seems like it is getting out into the weeds quite a bit)


Here’s (:key map) Uncaught TypeError: o.cljs$core$ILookup$_lookup$arity$2 is not a function at Function.cljs.core.get.cljs$core$IFn$_invoke$arity$2 (core.cljs:1836) at cljs.core.Keyword.cljs$core$IFn$_invoke$arity$1 (core.cljs:3172)


umm, arity$2 should be :key with two args, not just one if I'm not mistaken


but :key can take two args so there's still weirdness here


line 3172 calls this for the two args (-invoke [kw coll] (get coll kw))


eg. (:key) in my cljs repl complains that arity$0 is not a function


It’s puking here (-lookup ^not-native o k) in get


that's weird - makes me think something is wrong on a build tool level (though I have seen things go bonkers for odd reasons) - anything suspicious in recent changes to your codebase? you could try selectively undoing changes in a new branch to find the culprit


It’s a relatively new project. Here’s the build call and the top chunk of the single source file.

( "src/ui"
                      {:main 'theme-previewer.renderer
                       :output-dir "app"
                       :output-to "app/main.js"})
(ns theme-previewer.renderer
  (:require [cljs.nodejs :as nodejs]))

(def Electron (nodejs/require "electron"))
(def path (nodejs/require "path"))
(def fs (nodejs/require "fs"))

(.on (.-ipcRenderer Electron) "theme-path",
     (fn [sender payload]
       (.log js/console payload)
       (.log js/console (keys payload))


that seems legit...


hm. I’ll go hammock it out, maybe I can get it working in the morning.


@drewverlee just small help. think about strings, they have an encoding (subtypes of UTF, ISO, other). they are something that is meant to be displayed to a user (or written to an external data store, from which they will ultimately be used for display to the user). keywords don't have these semantics, they are purer (no encoding involved) and their semantics are just a means of communication between you and the compiler


oops old question


@jeff.engebretsen I'd bisect rather than hammock.


(not necessarily with git bisect, I normally do that manually, because I always get git bisect wrong)


There's nothing to bisect, it works without map operators but breaks with.


But it started occurring after something was changed/added. I'd track the culprit commit first.


The change was adding (:key map). The project is 1 day old with ~30 lines.


what's a good way to have a function be polymorphic according to an input's type? or is that an anti-pattern?

Drew Verlee23:04:48

@josh.freckleton Protocals dispatch via type

Drew Verlee23:04:02

its not an anti pattern. I think multimethods are strickly more flexible, but protocals are more performant.