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 clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
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 clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/4bdcef09-71db-b67d-796f-604e209f8a10%40gmail.com.
