This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-26
Channels
- # adventofcode (2)
- # announcements (7)
- # babashka (20)
- # beginners (77)
- # brompton (6)
- # calva (4)
- # clj-kondo (28)
- # clj-together (1)
- # cljdoc (2)
- # cljfx (10)
- # cljsrn (1)
- # clojure (77)
- # clojure-europe (33)
- # clojure-gamedev (12)
- # clojure-uk (11)
- # clojurescript (95)
- # clojureverse-ops (4)
- # core-async (4)
- # core-logic (1)
- # cryogen (2)
- # cursive (14)
- # data-science (3)
- # datomic (47)
- # duct (1)
- # emacs (7)
- # fulcro (51)
- # gratitude (8)
- # helix (14)
- # hoplon (4)
- # improve-getting-started (60)
- # jobs (1)
- # jobs-discuss (4)
- # joker (11)
- # lsp (99)
- # meander (62)
- # membrane (5)
- # news-and-articles (3)
- # off-topic (64)
- # pathom (3)
- # polylith (11)
- # practicalli (7)
- # react (1)
- # reagent (8)
- # reveal (15)
- # shadow-cljs (78)
- # specter (7)
- # sql (16)
- # tools-build (1)
- # tools-deps (29)
- # workspaces (1)
- # xtdb (17)
Here is an example nav
implementation. There is no difference between selecting either a key or a value from this map (e.g. in Reveal’s navigation dropdown it would say either (nav :a)
or (nav 1)
). In both cases whatever is the key in the relevant key-value pair becomes k
and whatever is the value becomes v
. This makes it impossible to disambiguate which part was actually selected, the key or the value?
Can someone explain if this is a limitation with Navigable, Reveal or my skills? Reveal itself seems to know the difference since it correctly displays (nav 1)
if I select the 1
for example.
(with-meta {:a 1 :b 2}
{`p/nav (fn [coll k v] [k v])})
I want to implement Navigable for some Clojure data structures, but I want to return different data depending on whether the key or the value is selected, so this part is tripping me up,
Reveal just adds minor niceties by suggesting correct nav call regardless of key or val selection
i.e. nav
only means "navigate to the key of that coll, and by the way the value was this", not 2 separate "navigate to key"/"navigate to value" functions
(ns datafy-fn
(:require [clojure.core.protocols :as p]))
(extend-protocol p/Datafiable
clojure.lang.Fn
(datafy [f]
(with-meta {:exec '...}
{`p/nav (fn [_ k v]
(case k
:exec (f)
v))})))
{:msg "Are you sure you want to quit"
:yes (constantly {:msg "Sure sure?"
:yes! #(System/exit 0)})}
I'd suggest experimenting with datafy/nav in REBL since it has idiomatic datafy/nav handling
I like to think of it as a square:
Object -datafy-> Data
/ |
/ |
nav get
/ |
L v
Object' Data'
datafy
takes you from objects to data; get
navigates in the data-world; nav
is like get
but takes you back to a "corresponding" object.(you can't easily navigate from Object
to Object'
directly -- and it's not always true that (datafy (nav (datafy obj) k v))
would get you from Object
to Data'
because the navigation is conceptual)
I guess I will just have to live with this limitation. I'm using the Navigable protocol to navigate an RDF graph in Apache Jena, so having to choose between either navigating to the object or the predicate part of the triple is an annoying limitation when both are resources with meaningful properties to query. But it's better than nothing 🙂 makes a lot of sense to think of it as like get
You probably can achieve what you want with different implementation for datafy, so your triple is datafied as a map with 3 keys — object, predicate, subject. Then you can nav further to any part of the triple
I don’t control the datafication, Luke Vanderheart does (I’m merely using/extending his Aristotle wrapper for Apache Jena). He was clearly aiming for it to look as much like Datomic as possible. Anyway, if I have to choose between either a 3-tuple vector and a map, I think I’ll have to go with the 3-tuple for a number of different reasons. The nav
implementation was just some sugar on top of a bunch of other improvements I’ve made while retaining overall compatibility.