You are right, I will do my best!

Do you have trouble with that?:-) Maybe it would be better but, IMHO, it doesn't matter.

The planned forking system would cover both of these scenarios. Its going to be a good bit of work, I hope to get started on it soon.

I would love for the fork kata system to allow other code warriors to write implementations of a kata in their preferred language too. Lots of nice kata in a single language at the moment.

Down the road, it could be a very cool feature if the community could collectively 'take over' a kata that's having problems and the creator seems to not be around.

Yeah the 3rd option is interesting but its a limited use case as its only relevant for numbers. Adding a Math.inRange helper would be more useful as you could then do something like

[1,4,6].filter(function(i){return Math.inRange(3,4, i)})

@icefox you good with changing to either of the first 2 options?

Yeah that would be nice. First things first though, I need to add the base ability to refactor/fix your solution. And before I can do that I need to add the ability to easily find your own solution within the list. Siggh... so much still to do.

I see a third possibility:

• creating arraies (or is it arrays?) -> Array.range( start, count )
• adding to arraies -> [].range( start, count )
• only accepting a certain range: [1, 4, 6].range( 3, 4 ) == [ 4, 6 ]

which would make sense in some applications, IMHO.

It's beta - it'll break, tough luck. But first poke Jake so that we get an e-mail if our solution is not valid anymore ;)

yeah I missed the non-for loop part in the description. Im personally a bit torn over this. On one hand, its encouraging usage of functional programming in a case where it probably shouldn't be used, on the other hand it makes the kata more fun for some users.

I think once benchmarking has been incorporated into the solution results than this isn't as big of an issue. Also, if some sort of "practical", "elegant", "goofy", "concise",etc voting was put into place then it would open up people to do whatever they want and still have the solutions be a valuable mentoring resource for developers.

In terms of the API. I would expect a method called Math.range to do something with numbers only, such as determine if a number is within a range. IMO Array.range is the most practical. [].range can make sense too, but having an instance method do something that has nothing to do with the instance that it is being called on is not a generally accepted good OOP design. Changing the instance method design so that it mutates the instance itself would be fine though. In fact, in that sense you get best of both worlds, you get to keep your [].range readability and also actually get more functionality out of it then if you just had Array.range.

With Array.range you are forced to create a new array, forcing you to manually merge it. With [].range you could do the following:

// only one array instance will ever be created
var ranges = [].range(1,5).range(8,2);
// ranges == [1,2,3,4,5,8,9]

In fact you could actually use that example as a test case and that would handle testing that the user is actually mutating the same array.

Making this change will break existing solutions but that comes with the territory when completing a beta that is in beta.

I can jump in and fix it for him. Just been slammed trying to get some new code pushed to the site. It sounds like everyone is in agreeance that there should be a hard limit on the string length?

I do wish that @hakt would chime in though. Maybe he felt that this "controversial" requirement gave the needed algorithm the complexity that he was aiming for. That said its probably best to decide on a canonical example to base this kata off of - such as how the rails active support library handles this.

Heh - you never used Latex, did you? Me always hates it when it decides a word is not to be truncated even though it's at the end of the line and it overlaps most ugly... So there IS an application for not truncating single words ;)

More serious: I think it's OK to say we want whole words, and if some overflow, so be it.

Perhaps he prefers having

truncate( 'buttonlaunchmissile, press this button only if you are sure', 6 ) == "buttonlaunchmissile,..."
truncate( 'buttonmaketea, press this button in the morning', 6 ) == "buttonmaketea,..."

instead of

truncate( 'buttonlaunchmissile, press this button only if you are sure', 6 ) == "button..."
truncate( 'buttonmaketea, press this button in the morning', 6 ) == "button..."

if you see what I mean ;) I just hope that this is NOT production code!

truncate('Thisismytestingfunction.',10) case is totally wrong accoring to the single word case. I put a most ugliest hack to pass the test.

I agree with this. I built my solution with this in mind.