> The only way to have `nav` selectively recognise keys based on their
> existence in the map, is to put its whole logic behind a `contains?` check.
> However that sounds counter-intuitive/productive...
Remember that nav is called with the key _and the value_ so it will be passed
whatever value is associated with the key in the data structure. So (nav data
:format nil) means either the key exists with the value nil or the key doesn’t
exist, but either way nil isn’t a valid format so your nav should just return
the value unchanged.
If (get data k) produces v, then nav will be called as (nav data k (get data
k)) – if v is part of data via some other “path”, then nav will be called as
(nav data nil v) so you always get v from data and you may get k from data. The
key, if passed, comes from the data structure – not some fabricated key.
If I do this:
(assoc (d/datafy (java.time.LocalDateTime/now)) :month {:name "MARCH" :value 3
:length 31})
When I navigate through the fields of that data structure to :month, I should
get a java.time.Month for March – because that’s the value passed into nav.
Your current implementation still returns February. That’s why nav should pay
attention to the value v that is passed in (again, per the docstring, nav
“Returns (possibly transformed) v, in the context of coll and k”).
The nav docstring:
“Returns (possibly transformed) v in the context of coll and k (a
key/index or nil). Callers should attempt to provide the key/index
context k for Indexed/Associative/ILookup colls if possible, but not
to fabricate one e.g. for sequences (pass nil). nav returns the
value of clojure.core.protocols/nav.”
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
From: dimitris
Sent: Monday, February 10, 2020 2:20 PM
To: [email protected]
Subject: Re: ANN: jedi-time 0.1.4
On 10/02/2020 20:45, Sean Corfield wrote:
> I’m suggesting that if you add certain key/value pairs to the datafied
> Java Time values, nav could recognize those as navigation from data to
> “stuff”. This gets you much closer to your original concept while
> staying within the datafy/nav confines.
The keys recognised by `nav` have been manually hard-coded to match the
keys in the map (in my current implementation), so if I add :format it
will always be recognised regardless of whether it exists in the map.
The only way to have `nav` selectively recognise keys based on their
existence in the map, is to put its whole logic behind a `contains?`
check. However that sounds counter-intuitive/productive...
> What I didn’t like about the original was that your nav function
> accepted arbitrary keys and values that weren’t related to the datait
> was “magic” and had extended navigation arbitrarily outside of the
> Clojure navigation of the data
I'm surprised you said that right after having shown exactly how I had
navigation for :format up until yesterday. What makes :format not
arbitrary or magic? How could `nav` possibly know that a new key has
been added (or removed/updated for that matter), and dynamically add the
corresponding behaviour?
> I don’t know how I would feel about the add/subtract time periods
> being done this way
Again, I find that interesting because if there is one operation that
naturally leads you from data to another Java object, that is shifting.
For example, the :format capability we're discussing leads you to a
String, whereas `(nav datafied :+ [2 :weeks])` leads you back to a
(datafiable) java object (i.e. a nicer fit for going from data to
stuff). The `:at-zone` and `:at-offset` navigation paths were similarly
good fits for the same reason. To me, :format although convenient and
all, is totally arbitrary.
> if you take data (the hash map produced by datafying a Java Time
> object) and manipulate the data in ways that preserves the nav
> metadata, then calling nav on that new data could do more things than
> calling nav on the original data
I honestly don't see how that is possible in the open way that you seem
to imply...Someone needs to define upfront what the `nav` capabilities
will be (what keys will be recognised), and those are not tied in any
way to the keys/values in the map at any given point in time. As I said
in my first point above, one could manually force that a navigation path
only fires if the key is actually contained in the data, but that sounds
like an anti-pattern if I'm honest.
I would love to understand a bit deeper why you thought that my original
nav keys felt arbitrary and magic, whereas you clearly think that
:format isn't...To me they all are, or none are.
Thanks again...
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/4bdcef09-71db-b67d-796f-604e209f8a10%40gmail.com.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/5e41de87.1c69fb81.29bce.3b9d%40mx.google.com.
