Ranges

[brendanator]

I really needed to specify a lower limit for the range of expansion. I see there is already a pull request that provides the lower bound but I've also implemented the upper bound. You can now write [#2..21# as shown below

[#2..4#def applyFunc[[#P1#], R](input: Tuple1[[#P1#]], func: ([#P1#]) => R): R =
  func([#input._1#])#
]

[marklister]

https://github.com/marklister/sbt-boilerplate/commit/7a4773d102cfae302128a63252a8dc4b846bb3c8 works pretty good but adds a dependancy to twitter-eval . In future I will probably redo this using scala's new JSR 223 support.

One cool feature is that [ 23 to 19 by -2# works. You can insert anything that evaluates to a scala Range

[marklister]

Whichever way you choose to go, I'd suggest sticking to existing scala syntax rather than inventing your own. In other words prefer [#2 to 21# rather than your syntax

[brendanator]

Yep, that makes sense to me too Either way, it would be good to get a new release with one of these in

[jrudolph]

Sorry for keeping you in the loop for so long. Actually, I like this suggestion as is. I'm not so much concerned about it not being Scala syntax, because all of the custom syntax here, isn't Scala syntax and I'd like to stay clear of introducing any extra dependencies.

@marklister Are you really using the feature to specify any possible Range expression?

[marklister]

I'm not using the range feature at the moment. However it will solve a tricky problem that I have been kludging my way around. I will change it into a jsr223 solution which will eliminate the dependency but only work on scala 2.11.

On 08 July 2014 11:51:36 AM WAT, Johannes Rudolph notifications@github.com wrote:

Sorry for keeping you in the loop for so long. Actually, I like this suggestion as is. I'm not so much concerned about it not being Scala syntax, because all of the custom syntax here, isn't Scala syntax and I'd like to stay clear of introducing any extra dependencies.

@marklister Are you really using the feature to specify any possible Range expression?

---

Reply to this email directly or view it on GitHub: https://github.com/sbt/sbt-boilerplate/pull/9#issuecomment-48321866

[marklister]

Let me describe the problem I'm trying to solve:

I have a collection of arity n which has a method returning a new collection of arity n+1. If the original collection is arity == maxArity I'd prefer to omit the method (causing a compile time error if used) instead of inserting some dummy methods that cause a runtime error.

I looked at this issue today -- it's going to be relatively easy to solve but will tie sbt-boilerplate to Scala 2.11.1. Is that acceptable? If not i'll just run my own fork and not bother you with pull requests.

If I get the go ahead I'd like to produce some separate Specs tests that test each feature. Is this OK?

[marklister]

And sorry, I should probably have commented on Issue #3

[jrudolph]

it's going to be relatively easy to solve but will tie sbt-boilerplate to Scala 2.11.1

How will that work with sbt 0.13.x still being on Scala 2.10?

[marklister]

How will that work with sbt 0.13.x still being on Scala 2.10?

Good point -- it won't!

[jrudolph]

Hi there, along with some other fixes I implemented this syntax proposal ([2 .. 20# ... #]) for now. This should again enable a few more cases while I agree that there are other cases where more general templating would be nice to have.

In any case, thanks for all the input!

[brendanator]

Awesome! Thanks