CLJ-1098 fix committed to Clojure master today as part of 1.5.0-RC3:
http://build.clojure.org/job/clojure/changes
Andy
On Jan 14, 2013, at 4:24 AM, Wolodja Wentland wrote:
> On Sat, Jan 12, 2013 at 08:15 -0800, Andy Fingerhut wrote:
>> The CLJ-1098 ticket was categorized as a minor enhancement when it was
>> created. Defects (i.e. bugs) are considered with higher priority.
>
> I can see that this categorisation caused this bug to be prioritised lower
> than actual bugs that break documented (or previous) behaviour. I also think
> that the categorisation is correct as the proposed change does, in fact,
> constitute an enhancement of the /current/ behaviour.
>
> The fact that this bug is an enhancement of the current behaviour as found
> for IKVReduce in the current stable releases and for CollFold in the current
> release candidates does, however, not mean that fixing it is not important, as
> the current behaviour is just unintuitive and not in line with the behaviour
> of nil in the context of other functions such as reduce.
>
> I consider the "decision" to special case nil for reduce-kv and, soon, for
> the reducers library a poor one. Fixing this oversight is very easy right now
> and should be done as soon as possible and in particular before we find
> libraries littered with (nil? coll).
>
>> Also Clojure 1.5.0 is nearing release [1], and pretty much any software must
>> reduce its rate of changes near release so more testing can be done on a
>> single version (or at most a few versions with minimal changes between them,
>> if problems are found).
>
> Introducing reduce-kv was an important part of the 1.4 release and the
> reducers library will be even more important for 1.5 and it should be a
> priority that these two integrate well into the Clojure ecosystem and behave
> in line with our expectations. The reducers library is even advertised as a
> drop-in for existing codebases, but the implementation right now does not live
> up to that and requires authors to special case nil, which is simply ugly.
>
>> If your concern is that it isn't being committed as fast as you would like
>> it to, you have joined a new club. Welcome. :-) Until that ticket is
>> considered and applied or rejected, you may create your own patched version
>> of Clojure, and if you wish even distribute it under the Eclipse Public
>> License, but those approaches might not suit your purposes.
>
> Well, I am sure that many people have their particular bug they would like to
> see fixed, but I think it is a bad idea to /not/ fix this bug in 1.5 as the
> reducers library violates expectations as it is now. One also does not /have/
> to see the patch as an atomic one and I guess implementing only CollFold for
> nil is an improvement over the status quo if doing so for IKVReduce is not
> wanted (for whatever reason).
>
> I was simply curious about why this has not been done in the first place and I
> still do not see a good reason for doing so. I guess the main point I am
> trying to make here is: Better fix it now before maintaining historic
> behaviour/naming (such as the contains?-wart) becomes the only argument for
> not applying the (very simple) patch.
>
> If it is too late, then it is too late … but then I still don't understand
> this design decision.
> --
> Wolodja <babi...@gmail.com>
>
> 4096R/CAF14EFC
> 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
--
--
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
