Easy to explain - absolutely, consistent - mm, not really...
I found this new behavior a bit confusing, imo it breaks principle of
least surprise.
This feature is uncommon in dynamic languages (even Scala allows
duplicate keys - Set('a,'a)/Map('a->1,'a->1)).
Also, from the practical point of view
I agree that duplicate keys in literals are probably a coder error but
IMO this deserves some kind of compiler warning rather than an error.
You're going to get into lots of sticky situations otherwise that only
confuse people if the semantics are different between literals and
other usage. Simple
Can I change the title to:
"Duplicate key error handling feature in hash-sets" ?
I was using the '#' thinking it was short for a hash-map, rather than
a hash-set.
Clojure has more data structures available than I'm used to working
with.
So thanks for the error handling.
Tim
On Jun 25, 9:37 a
On Fri, 25 Jun 2010 11:37:32 -0400
Stuart Halloway wrote:
> (2) The need for both flavors. If there wasn't a flavor that rejected
> duplicate keys, somebody would surely ask for it.
I guess it makes as much sense as anything, given that you don't want
to get into -unique or some such.
But it d
I think there are two important considerations in favor of how it works now:
(1) The "common case" presumptions (which admittedly may need to be learned).
(2) The need for both flavors. If there wasn't a flavor that rejected duplicate
keys, somebody would surely ask for it.
Add to these conside
On Fri, 25 Jun 2010 10:31:57 -0400
Stuart Halloway wrote:
> Duplicate keys in maps/sets are disallowed in literals and factory functions,
> where data is generally literal & inline and therefore likely represents
> coder error:
>
> ; all disallowed
> #{:a :a}
> {:a 1 :a 2}
> (hash-map :a 1 :a
Duplicate keys in maps/sets are disallowed in literals and factory functions,
where data is generally literal & inline and therefore likely represents coder
error:
; all disallowed
#{:a :a}
{:a 1 :a 2}
(hash-map :a 1 :a 2)
(hash-set :a :a)
They are allowed in other contexts, where the data coul
>
>
> Apparently, duplicate keys in sets are only disallowed in set
> literals. Arguably, that must be a mistake on the users part, but
> it sure seems to clash with the behavior of sets elsewhere.
>
>
Why would you ever want to write a duplicate in a set literal?
--
You received this message bec
On Fri, 25 Jun 2010 15:36:31 +0200
Michael Wood wrote:
> On 25 June 2010 12:27, Tim Robinson wrote:
> > I tried Clojure via Githhub today.
> >
> > Anyone notice this bug that hadn't existed in Version 1.1
> >
> > user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
> > java.lang.IllegalArgume
On 25 June 2010 12:27, Tim Robinson wrote:
> I tried Clojure via Githhub today.
>
> Anyone notice this bug that hadn't existed in Version 1.1
>
> user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
> java.lang.IllegalArgumentException: Duplicate key: {:a "A", :b "B"}
You're trying to put dupl
Duplicate key prevention is a feature added in commit
c733148ba0fb3ff7bbab133f5375422972e62d08.
Stu
> I tried Clojure via Githhub today.
>
> Anyone notice this bug that hadn't existed in Version 1.1
>
> user=> #{:item1 {:a "A" :b "B"} :item2 {:a "A" :b "B"}}
> java.lang.IllegalArgumentExceptio
11 matches
Mail list logo