Re: Type hints for clojure.set functions

Looks great, Andy. -- -- 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 gro

Re: Type hints for clojure.set functions

I created a slightly modified version of clojure.set and have released it as funjible.set More info here, if you are curious: https://github.com/jafingerhut/funjible Andy On Mon, Sep 30, 2013 at 8:00 PM, splondike wrote: > If it's a case of prioritization, that makes sense. I was going t

Re: Type hints for clojure.set functions

If it's a case of prioritization, that makes sense. I was going to suggest raising a bug, and then triaging it as low priority, but I notice that there is already a declined JIRA issue. I apologize for not checking there before adding this thread. I'

Re: Type hints for clojure.set functions

Hi splondike, I disagree with your arguments about what is sensible -- *any* behavior is sensible when you violate the contract of an API. Of course everybody could get behind the "throwing the error" plan if the cost of throwing that error was zero: zero assessment cost, zero development cost,

Re: Type hints for clojure.set functions

Thanks for the comment. The current behaviour is sensible for the code branch where the second argument is the same length or shorter than the first (see my first post). It is the other branch that does not do what you would expect. My real issue though is how the behaviour changes dramatically

Re: Type hints for clojure.set functions

I think the bar for such an enhancement is fairly high, and the value delivered fairly low. It isn't so much the impact of assessing this single change, as the impact of managing the universe of such changes. Regards, Stu -- -- You received this message because you are subscribed to the Google

Re: Type hints for clojure.set functions

Idiomatic was probably the wrong word since we don't want to arbitrarily restrict options in a dynamic language. In this case where the results are unexpected and inconsistent in other cases, would this check be acceptable? On Sunday, September 29, 2013 1:55:05 PM UTC-4, splondike wrote: > > Tha

Re: Type hints for clojure.set functions

Thanks for the comments, you are correct that type hintingis only to support performance optimization, no exceptions are thrown. The source for the set function suggests that it would not be free to call on sets, it converts its argument

Re: Type hints for clojure.set functions

On Sep 28, 2013 1:47 PM, "splondike" wrote: > > Can anyone else think of a reason why we should not add type hints to the functions, or why coercing the arguments to sets is better (or something else I haven't thought of)? IIRC, type hints are only used by the compiler to generate non-reflective

Type hints for clojure.set functions

I just got burned by the clojure.set/difference function (v 1.5.1) wherein I had in error passed a vector for the second argument. This causes inconsistent results depending on the relative lengths of the arguments. That is, as soon as the second argument becomes longer than the first we get a