This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-27
Channels
- # adventofcode (1)
- # announcements (4)
- # beginners (120)
- # calva (5)
- # cider (12)
- # clara (3)
- # cljdoc (48)
- # cljs-dev (33)
- # cljsrn (4)
- # clojure (124)
- # clojure-dev (43)
- # clojure-europe (2)
- # clojure-italy (168)
- # clojure-nl (2)
- # clojure-spec (7)
- # clojure-uk (79)
- # clojurescript (50)
- # core-logic (6)
- # cursive (12)
- # datascript (1)
- # datomic (8)
- # devcards (2)
- # emacs (5)
- # events (2)
- # figwheel-main (6)
- # fulcro (18)
- # graphql (42)
- # hyperfiddle (3)
- # jobs (1)
- # luminus (2)
- # nrepl (5)
- # off-topic (59)
- # onyx (5)
- # parinfer (2)
- # pathom (10)
- # pedestal (2)
- # portkey (3)
- # re-frame (24)
- # reagent (6)
- # reitit (54)
- # remote-jobs (1)
- # ring (5)
- # shadow-cljs (75)
- # spacemacs (35)
- # sql (22)
- # tools-deps (16)
- # unrepl (10)
Alex's response to the "Why not IFn?" question reminds me of a viewpoint on clj maps I've had for a while but haven't heard anybody else articulate (you could apply this to other dynamic languages too)
that their use falls into two disjoint patterns
A) homogeneous maps, which are unbounded in size and have keys of one specific type and values of another specific type (i.e., s/map-of
)
B) heterogeneous maps, which have keys that are names taken from a known and probably very small set, and the values are arbitrary but typed specific to individual keys (i.e., s/keys
)
so my interpretation of alex's comment about defrecord is that "defrecord is only for type B"
In Rich speak, “mechanism vs information”
and also I would say that the IFn interface is only for type A
I think of IFn on map (and get
) being for type A, while IFn on keywords is for type B
Instead of IFn for keywords, I would call it ILookup
ILookup is the interface the arg is expected to satisfy, right?
well right
okay, so I was talking about (:foo m)
calls; it's true that m
satisfies ILookup
in this case, but it's the fact that the keyword is being called as a function that I want to highlight, so I can't see why talking about "IFn for keywords" doesn't accomplish that
I assume the ILookup comment also applies to (get m :foo)
, so it wouldn't seem to distinguish the case I'm trying to
there's a parallel distinction you could make for sequential structures; sequences vs tuples, or something of that sort
most statically typed languages have totally different constructs for the different cases, so distinguishing them isn't as useful
can also be interesting to note that JSON seems aimed at a paradigm where type A doesn't exist -- that's why its maps can only have string keys
Woah does defstruct still exist
I haven't thought about it in like seven years
Niiiiiiiiice
Does it compile to a special class?
I am reading the datatype official material at https://clojure.org/reference/datatypes#_deftype_and_defrecord And it mentions “host-in-parens constructs” What is the meaning of “host-in-parens constructs” in this context? ” They support, in a relatively clean manner, access to the highest-performance primitive representation and polymorphism mechanisms of the host. N.B. that they are not merely host-in-parens constructs. ”
i take this to mean they are not merely host constructs "parenified". ie, they aren't just java classes written with parens instead of {
They are exactly the same as if you invoked a java object through a polymorphic method in Java (there is no extra Clojure var overhead or anything)
You mean from a performance perspective?
From all perspectives :)
But yes, the implication is perf
So conceptually, they are different: they are opiniated , they are the Clojure way of doing OO but there are no performance penalties for that.
In short: We benefit from the best of both worlds
fast case is fast, “slow” case is open (still fast due to cache)
is it expected that AOT compiled namespaces lose metadata?
$ clj -Sdeps '{:deps {datascript {:mvn/version "0.16.8"}}}'
Clojure 1.9.0
user=> (require 'datascript.arrays)
nil
user=> (find-ns 'datascript.arrays)
#object[clojure.lang.Namespace 0x76911385 "datascript.arrays"]
user=> (meta (find-ns 'datascript.arrays))
nil
I was going to say "expected in that it is a known issue" but it looks like maybe it should be fixed, it may depend on the version of clojure the ns was aot compiled with
Thanks guys!