On 4/10/16, 2:53 AM, "mattias w" wrote:
> With clojure 1.8, we got many of these functions, but not str/length and
> str/substring.
Because we already have `count` and `subs` in clojure.core
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying som
With clojure 1.8, we got many of these functions, but not str/length and
str/substring.
What am I missing?
/mattias
Den fredag 1 november 2013 kl. 19:40:42 UTC+1 skrev Sean Corfield:
>
> This thread made me run a quick audit of our code and we had about a
> dozen calls to .length, a dozen cal
This thread made me run a quick audit of our code and we had about a
dozen calls to .length, a dozen calls to .substring, and a handful of
calls to .replace - of which a few were in truly performance sensitive
code (doing Unicode-related processing across large strings, so they
had lots of other Ja
On Thursday, October 31, 2013 10:37:33 PM UTC-5, Mikera wrote:
>
> OTOH, count is much more generic since it can handle arbitrary sequences
> etc. Also count doesn't require type hints. You should definitely prefer
> count when writing most high level code.
>
Yes, I'd prefer count in higher le
On Wednesday, 30 October 2013 18:44:47 UTC+8, Alice wrote:
> Which one is preferred?
>
> .length needs to be type hinted, so more verbose.
> The performance penalty of count is negligible in most cases.
>
Doing a quick micro-benchmark with criterium I get:
- .length at 5.5 ns
- count at 50.0 ns
I meant collection ... not sequence.
Luc P.
> Strings are character sequences, count is a better option to stay
> within the sequence abstraction.
>
> Lic P.
>
>
> > count does some type checks, but it's negligible in most cases as I already
> > said. len can give a clear intention than cou
Strings are character sequences, count is a better option to stay
within the sequence abstraction.
Lic P.
> count does some type checks, but it's negligible in most cases as I already
> said. len can give a clear intention than count somtimes.
>
> I'm not suggesting that it should be included
count does some type checks, but it's negligible in most cases as I already
said. len can give a clear intention than count somtimes.
I'm not suggesting that it should be included in clojure.string, but if
count is currently not preferred over .length, including it can be a good
option.
On We
What'd clojure.string/len do any differently than clojure.core/count?
count already provides does the fastest possible thing for strings.
~BG
On Wed, Oct 30, 2013 at 4:14 PM, Alice wrote:
> Which one is preferred?
>
> .length needs to be type hinted, so more verbose.
> The performance penalty of
