Multiple key-value pairs in assoc-in (old issue)

[Łukasz Kożuchowski]

Hello,

Currently assoc-in does not support multiple key-value pairs the way
assoc does.

user=> (assoc {} :a 1 :b 2)
{:b 2, :a 1}
user=> (assoc-in {} [:a :b] 1 [:c :d] 2)
ArityException Wrong number of args (5) passed to: core$assoc-in
clojure.lang.AFn.throwArity (AFn.java:437)

It appears a patch for this has been ready for more than a year:
http://dev.clojure.org/jira/browse/CLJ-1771

Can we expect this to work soon?

--
Łukasz Kożuchowski

[Andy Fingerhut]

That ticket is in a state called "Triaged", which means that a screener (most likely Alex Miller) thinks the issue is good enough for Rich Hickey to take a look at it some time.  Rich probably hasn't looked at it yet, because if he had, it would have likely been changed to Declined or Vetted.

As far as expectations go, there are enough other things being worked on for Clojure 1.9 that I would not bet any money this ticket will make it in to that version.  Disclaimer: I am only an observer in this, not a decision-maker.

Andy

--
  Łukasz Kożuchowski

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Łukasz Kożuchowski]

I am a little sad now. Thanks for explaining!

Łukasz Kożuchowski

[Andy Fingerhut]

Of course you can copy the newer definition of assoc-in into your own projects and use it if you like, but that probably doesn't prevent your little bit of sadness.

Andy

Sent from my iPhone

clojure+u...@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+u...@googlegroups.com.

[Łukasz Kożuchowski]

Thanks for the tip. I imagine the patch author is much more sad (it's been one year...).

Łukasz Kożuchowski

[Timothy Baldridge]

When I see mailing list posts like this I like to play the devil's advocate a bit (at least in my own mind) and try to find problems with including a given patch in Clojure. 

A few things to consider:
1) There are really three answers to patches: "yes", "no" and "not now". That is to say, because a patch hasn't been accepted doesn't mean it's bad, it just means that it may not be the right time for the patch or perhaps there are other tickets more pressing for the version of Clojure under development. So don't let the time since patch creation disappoint you, it doesn't mean all hope is lost. 

2) Now I ask myself: "Why would this be in core?" Looking at this function I see something interesting, there's nothing about this patch that couldn't be added as a utility function in some separate project. So why would I want to force the maintainers of Clojure, now and in the future, to support some extra logic? The best reason I can come up with is that it saves me copy-and-pasting some util function around, or perhaps it keeps me from including another util dependency in my projects. Is that convenience worth the cost? I don't know, and that's not my job, thankfully :) . 

3) Now I ask my self: "When have I needed this feature?" And sadly, I can't think of a case. That's not to say I haven't needed to call assoc-in on many path/value pairs, but when I do I often use a construct like this:

(reduce-kv assoc-in {}

 {[:a :b] 42

  [:c :d] 43

  [:d] 11})

In fact, I've been thinking about this for several days, and I have yet to think of a situation where I'd prefer 'apply' over reduce. And I can't think of a situation where I've need multiple hand-written arguments to assoc-in.

I also think I haven't needed this functionality because I tend to prefer namespaced keywords and flat maps. Or when I do have nested maps, I use something like prewalk to do my work. This is anecdotal evidence, but it's my experience. 

None of these things are huge, but that's my thought process when reading about patches. 

Timothy

On Mon, Aug 15, 2016 at 6:53 PM, Łukasz Kożuchowski <lukasz.ko...@gmail.com> wrote:

Thanks for the tip. I imagine the patch author is much more sad (it's been one year...).

Łukasz Kożuchowski

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Paulus Esterhazy]

Just this week I have wished for an extended version of `assoc-in`
more than once. The reason is convenience, e.g. in the context of a
ring middleware:

(assoc-in response
[:headers "Location"] "/homepage"
[:session :user-id] user-id)

Extending `assoc-in` would also achieve parity with `assoc`, which
does accept multiple kv pairs.

>> clojure+u...@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+u...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.

[Andy Fingerhut]

Anyone who has created a free JIRA account can vote on Clojure tickets.  High-voted tickets get Alex Miller's attention so he can try to make progress on them, with some level of priority over tickets without votes.  Note that in some cases, 'making progress' can simply mean 'declined sooner, rather than later'.

Just go to the page fora ticket, like this one: http://dev.clojure.org/jira/browse/CLJ-1771

Click the "Log in" link near the top right if you don't see your name there, and if you don't have an account, you can create one.

I generate lists of top-voted tickets every week or so, available here: http://jafingerhut.github.io/clj-ticket-status/clojure-ticket-info.html

Andy

>> clojure+unsubscribe@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+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.

[Łukasz Kożuchowski]

On 08/18/2016 09:46 PM, Andy Fingerhut wrote:
> Anyone who has created a free JIRA account can vote on Clojure tickets.

Wow. That's nice. Just voted. Thanks for the info. I thought it's only
for contributors.

I'm not really complaining, just wanted to know what's going on and
possibly bump the issue. I understand everyone is busy and everything
has a priority.

--
Łukasz Kożuchowski

[Alex Miller]

I'm not convinced this is even a good idea (but Rich is the ultimate judge). None of the -in fns repeat paths like that so this makes assoc and assoc-in similar but makes assoc-in / update-in etc inconsistent.