Enhanced to allow control over the start index

[joescii]

In my project SNMP4S I needed sbt-boilerplate to skip the i = 1 iteration. I enhanced my fork of sbt-boilerplate to allow specifying the start index (In my case, I set it to 2). This is what it looks like:

[2#abc ##1 # ++ ]

Of course, if you omit the 2, the behavior is as before. Let me know if you like this enhancement. I can update the README as well.

Thanks for building such a handy plugin!

-Joe

[marklister]

Would it be very difficult to add the end?

Something like [1..22# That would then fix the limitation described in the README.md and I'm sure someone will ask for it soon.

[joescii]

Shouldn't be too difficult. I initially thought about doing it, but decided not to build more than I needed unless someone thought it was useful. I'll update the README as well.

[marklister]

My syntax suggestion is probably suboptimal... Something that matches scala's Range syntax is probably the way forward. I might have a hack on this tomorrow, time permitting.

[joescii]

That's an interesting idea. It would be cool if you could put an arbitrary expression in there which produces a range. I bet that could be passed off to the interpreter for evaluation.

[marklister]

That's exactly what I had in mind! There's some sort of interpreter in scala.tools.nsc .... What would be nice is to provide a context to the interpreter so that it could inspect it's environment etc.

What I had going on in my head was:

[scala-code-that-evals-to-Range# 

template stuff
....
$$scala-code-that-evals-to-a-string$$
...
#scala-code-that-evals-to-String]

The stuff between the $$ would allow you to do something like: $$(context.maxArity+1).toString$$

And I'm sure $$ won't be a good delimiter, but you get the idea...

see: http://stackoverflow.com/questions/12122939/generating-a-class-from-string-and-instantiating-it-in-scala-2-10

[marklister]

But maybe wait to see what @jrudolph has got to say before putting in any work...

[joescii]

Yep, not a bad idea. I spent my evening hacking out a sane approach to my problem that needed this library in the first place.

[marklister]

I pushed a commit to my fork: a feature branch called: range-eval. At the moment it accepts any string between [ and # then evals a scala.collections.immutable.Range.

I don't want to spend too much time on sbt-boilerplate but, in order to make it fit my requirements, I might end up doing the following:

• Create an EvalContext object containing maxArity, i, etc (A new one for each Expand)
• Eval anything within delimiters (I'm leaning towards backticks)
• drop replacement of 0, 1, 2 (this will become i-1, i and i+1 -- in backticks)

Comments welcome. @jrudolph do you think this is something you'd want in sbt-boilerplate? If not, no problem: I'll maintain my own fork.

Current example:

 Template:
 [ 23 to 19 by -2 #abc Tuple1 #]

 Generated Code:
 abc Tuple23 , abc Tuple21 , abc Tuple19

[joescii]

FYI, Scala already utilities back ticks: http://stackoverflow.com/questions/6576594/need-clarification-on-scala-literal-identifiers-backticks

I don't quite follow why you would need them. Are you saying they would be in the template that gets repeated?

[marklister]

@barnesjd, thanks for the backtick info -- saved me from one poorly researched bad design decision. Why I need a delimiter? One use case I have is a class of Arity n that has a method returning a class of Arity n+1. For my class of Arity 22 I want to simply omit the method rather than defining a stub implementation of Arity 23 that throws exceptions.

So within the template I'd have:

[#
class Item@i@{
  def bigger: Item@i+1@ = ???
}
#]

Where @...@ are delimiters

Eventually the def bigger part would be enclosed in delimiters with a if (i<maxArity) "def bigger ..." else "" eval section.

[jrudolph]

See https://github.com/sbt/sbt-boilerplate/commit/df2ad7c83b8cc1ef00e1e0fc446121879057d77d#diff-8a709cc1e5a18e5869d604b472d316aeR38 for the new custom Range syntax available in 0.5.9.

Still, thanks for this proposal.