@emccue Yeah, here's the list of types behind a bare defrecord:

user=> (defrecord Foo [])
user.Foo
user=> (->> Foo ancestors (map str) sort clojure.pprint/pprint)
("class java.lang.Object"
 "interface clojure.lang.Associative"
 "interface clojure.lang.Counted"
 "interface clojure.lang.IHashEq"
 "interface clojure.lang.IKeywordLookup"
 "interface clojure.lang.ILookup"
 "interface clojure.lang.IMeta"
 "interface clojure.lang.IObj"
 "interface clojure.lang.IPersistentCollection"
 "interface clojure.lang.IPersistentMap"
 "interface clojure.lang.IRecord"
 "interface clojure.lang.Seqable"
 "interface java.io.Serializable"
 "interface java.lang.Iterable"
 "interface java.util.Map")
nil

thats unfortunate, but whatever

kinda stinks that so much of the functionality in clojure is in interfaces and not protocols

For comparison, deftype provides almost nothing:

user=> (deftype Bar [])
user.Bar
user=> (->> Bar ancestors (map str) sort clojure.pprint/pprint)
("class java.lang.Object" "interface clojure.lang.IType")
nil

yeah its not really worth it for me to use deftype

ill just stick to a specific function

Why do you need to override count for a record? (I'm curious as to the use case)

progress bar

I'd be concerned that it would break a bunch of core functions if your count isn't just the underlying count behavior...

10 states on a history, user steps through 5

ill just define a history/length

That seems better than overloading a standard, built-in behavior...

I need to add the "I am a bad programmer" disclaimer to my username

ill roll with that

curious what the technical difference is between protocols and interfaces though

like, what is the difference in bytecode that makes it so I can extend any type with a protocol but not with interfaces

Protocols are interfaces, when the type is defined after the protocol. When the protocol is defined after the type, protocols find the function to call by looking up the type in a hashmap, and that result is cached sometimes

@emccue ^^