This is covered in the coding standards doc [1]: "Use type hints for functions
that are likely to be on critical code; otherwise keep code simple and
hint-free."
Reusable libraries are a strong candidate for type hinting.
[1] http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Stan
My memory was bad. There's no rampant bug in the code if one does not place
type hints. My bad.
2010/5/29 Dennis
> However, in this case, the point of the code was probably to
> show/teach somebody how to solve a problem. When teaching, you want
> to make the point as clear as possible, and I t
However, in this case, the point of the code was probably to
show/teach somebody how to solve a problem. When teaching, you want
to make the point as clear as possible, and I think John is trying to
point out, in this instance, the extra code to remove the reflection
warnings detracts from that go
Thank you for great solution.
On 28 май, 23:45, Laurent PETIT wrote:
> 2010/5/28 Michael Gardner
>
> > On May 28, 2010, at 12:42 PM, Laurent PETIT wrote:
>
> > > The rule should really always be: no warning at all (with
> > *warn-on-reflection* set to true, of course).
>
> > I strongly disagree.
2010/5/28 Michael Gardner
> On May 28, 2010, at 12:42 PM, Laurent PETIT wrote:
>
> > The rule should really always be: no warning at all (with
> *warn-on-reflection* set to true, of course).
>
> I strongly disagree. Why should you care about those sorts of warnings
> unless you've already identif
2010/5/28 Michael Gardner
> On May 28, 2010, at 12:42 PM, Laurent PETIT wrote:
>
> > The rule should really always be: no warning at all (with
> *warn-on-reflection* set to true, of course).
>
> I strongly disagree. Why should you care about those sorts of warnings
> unless you've already identif
On May 28, 2010, at 12:42 PM, Laurent PETIT wrote:
> The rule should really always be: no warning at all (with
> *warn-on-reflection* set to true, of course).
I strongly disagree. Why should you care about those sorts of warnings unless
you've already identified a bottleneck that needs eliminat
The rule should really always be: no warning at all (with
*warn-on-reflection* set to true, of course).
And in this case, I did what is necessary to avoid reflection warnings. Try
it yourself.
2010/5/28 John Cromartie
> I feel like the type hints should be left out until you really need
> them,
I feel like the type hints should be left out until you really need
them, since they kind of clobber the routine's readability.
-John
On May 28, 9:07 am, Laurent PETIT wrote:
> (reduce
> (fn [#^String s [#^CharSequence what #^CharSequence with]]
> (.replace s what with))
> "Foo12 Bar130
(reduce
(fn [#^String s [#^CharSequence what #^CharSequence with]]
(.replace s what with))
"Foo12 Bar130 Qoo20"
{"Foo" "XF" "Bar" "XB" "Qoo" "XQ"})
2010/5/28 Oleg
> Hello Guys!
>
> I have a string for example "Foo12 Bar130 Qoo20" and map like this
> {"Foo" "XF" "Bar" "XB" "Qoo" "XQ}.
>
10 matches
Mail list logo
