Support running RLTK on Ruby 1.8.7.

[jimsynz]

I'm using RLTK for a project I'm working on which hopes to maintain compatibility with Ruby 1.8, which necessitated making RLTK work on Ruby 1.8.

Changes:

• Change instances of Ruby 1.9 hash syntax to hashrockets.
• Change instances of Ruby 1.9 stabby to proc keyword.
• Change double splat method arguments to concat + splat.
• Explicitly rescue LoadError when loading the cg test suite.

Caveats:

• I had to disable ParserTester#test_use on 1.8 because the inherited hook is called after class definition when using anonymous classes on 1.8. This is fixed on >= 1.9. (See: http://bugs.ruby-lang.org/issues/4273)

[chriswailes]

This is, in fact, the exact opposite direction from where I'd like to take RLTK. I'm trying to move to using as many Ruby 2.0 features as possible. Soon this will include keyword arguments, nested methods, more break values, and heavier use of the stabby proc syntax.

While I won't merge this into the master branch I would be willing to work with you and help maintain a branch specifically for 1.8. The compatibility branch could then be published as a rltk-compat gem, perhaps.

[jimsynz]

That's a total bummer :(

Do any of the mentioned Ruby 2.0 features actually allow for new features or improvements to RLTK itself?

I guess I'll maintain my branch for now.

[chriswailes]

Yes, I feel that keyword arguments lead to cleaner APIs and break values clean up code. As well, I want to use lazy enumeration and the prepend feature in parts of the project.

Another part of it is I don't want to feed the cycle of "Why should I use Ruby 2.0, no projects are written in it," and "No one is using Ruby 2.0 so I should develop my project for 1.8." From I can tell that is one of the problems with Python 3. I think it's best to just start porting things over and make sure the process is as easy as possible for people.

[jimsynz]

Right, I guess that's why I really want to implement keyword arguments in Rubby once I get the basic functionality implemented. I can see lazy enumerators, especially, cleaning up the RLTK code base, now that you mention it.

As far as 1.8 goes, I don't need any new features, just the occasional bugfix. Perhaps we could do a 2.2 release with 1.8 support locked in, and then make 2.3 (or even 3.0) require Ruby 2? That way people who have ~> 2.2 in their gemfiles won't have things unexpectedly break on them? Could even add a post-install warning telling them that all future versions would be Ruby 2 only. Does this sound like a decent compromise?

I intend to eventually drop support for 1.8, but not quite as quickly as you do :)

[chriswailes]

If you are happy with the state of the master branch as it is I can branch, apply your patch and make one last release with 1.8 support.

I don't know when I'll release the next version of RLTK, but it will certainly be after I add LLVM 3.2 support. I'll probably also increment the major version number as well. The post-install warning is also a good idea.

[jimsynz]

That'd be awesome. Thanks!