the issue here is that behaviour should be *consistent* across all forms
of ctor functions, so programmers don't have to remember which one
allows what or don't thus limiting code breaks...the literal syntax is
just too elegant to give up! I don't think anyone is against consistency...
Jim
ps: IMO sets should always remove duplicates quietly...that is the whole
point of using them programmatically!
On 04/09/12 17:30, Andy Fingerhut wrote:
I have created a dev page for this issue. It isn't a JIRA ticket because it
isn't clear to me yet exactly what the changes should be.
http://dev.clojure.org/display/design/Allow+duplicate+map+keys+and+set+elements
A couple of questions there for people that dislike the current behavior.
You can always construct sets that quietly allow duplicates as follows. Is
that good enough? Or perhaps the issue is that you prefer to use #{} notation
for constructing sets, and do not want to have to use a different method if you
want the silent-duplicate-elimination behavior? If so, I can understand that.
I'm just trying to get the argument for change as clearly as possible.
(set [a b])
The story for creating maps that quietly use the later duplicate keys in
preference to the earlier ones isn't as clean: both hash-map and array-map
throw an exception on duplicate keys, although sorted-map does not for some
reason (probably an oversight when the duplicate key checks were added?). The
following works, but is a bit clunky:
(assoc {} a 5 b 7)
Thanks,
Andy
On Sep 3, 2012, at 7:49 PM, Sean Corfield wrote:
On Mon, Sep 3, 2012 at 6:06 PM, Mark Engelberg <mark.engelb...@gmail.com> wrote:
I don't know what the path is now. I feel that in the past year, there have
been several times where people have raised meaningful issues about Clojure
and received no official response. It's hard to know whether this is an
intentional "rejection through ignoring", or whether it's just that those
messages happened to slip beneath the radar. Maybe Rich didn't see them,
and without his go-ahead, no one moved forward with them.
My understanding is the sort of discussion you are referring to has
moved to clojure-dev by necessity because of the volume of posts on
this list. http://clojure.org/contributing hints as much.
My understanding is also that anyone can open an issue in JIRA for
something they believe is a bug.
In any case, there was a great deal of useful discussion about the set
issue, and then... silence.
Open an issue in JIRA. Ask the folks here who agreed with your point
of view to "vote" on the issue. All issues get raised on clojure-dev
one way or another (esp. if they have a patch attached).
example, on whitehouse.gov, you can start a petition and if enough people
sign the petition within a given length of time, the president's office will
issue an official statement about it. That's the kind of thing I'm thinking
That would seem to match the "voting on JIRA issues" point above.
2. There was significant support for my suggestion to revert set behavior
back to 1.2 and solve the problem which motivated the change by bringing
array-maps into accord with the behavior of the other maps and sets. This
email is also my way of bumping the thread and bringing it again to
everyone's attention. This is something I'd very much like to see resolved.
Again, open an issue in JIRA with a patch (you have a signed CA on
file so there's no obstacle). That will guarantee the issue gets
reviewed.
--
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
