Any compatibility with 1.9x? about database_rewinder

[wideopenspaces]

@dannguyen I just tried to run it on 1.9 and it won't work. Looks like it uses named arguments.

[amatsuda]

I know that it's technically not that difficult to rewrite my code here to work under 1.9.
Just replace kwargs with AS extract_options, Module#prepend with AMC, then we will obtain 1.9 compatibility (in exchange for a bit of readability IMO).
And your patches welcome.

However, I'm sure I sooner or later will break the compatibility again since I do no more use 1.9 personally.
I usually live on 2.1, and sometimes switch back to stable 2.0, but do never willingly do rbenv use 1.

So now let ME ask you a question.
Is there any good (or inevitable) reason for your to stay on Ruby version one?
I guess it's much easier to migrate YOUR code to Ruby 2 than to keep maintaining my code compatibility forever, in terms of the greatest happiness of the greatest number of programmers. Isn't it?

[dannguyen]

As you state yourself, the regression from introducing 1.9-compatible-code would be a loss in readability. Is that a worthwhile tradeoff for lower adoption? That's only something that should matter to you, the author, as it's your time, your labor of love, etc.

However, it is not realistic to expect everyone to migrate to 2.x. It's not always up to an individual coder. For my situation, I could probably upgrade some existing projects to 2.x without too much trouble. But think of the situation here. Your library is a replacement for database_cleaner...both libraries are very helpful and make coding more of a joy, so that in itself is a credit to you and should be credit enough. However, it is not an essential library in the same way that Rails is. Or any of the SQL wrappers...if those required an immediate move to 2.x, then I'd probably make that change (as long as the migration/bug-checking time was manageable). But I couldn't justify the jump in versions just to have a faster database cleaner, because while database_rewinder might make life more enjoyable in the testing phase, it may not be worth the pain it makes elsewhere.

I don't know enough about database_rewinder's code or about Ruby 2.x to make any judgment on how sticking to 1.9 will stunt its potential. But I would take the bet that compatibility with 1.9, if it could be done without a loss in current features, would most undoubtedly impact a greater number of programmers than sticking to just 2.x. Not just now, but in the future -- it's reasonable to assume that when 1.9 is no longer supportable by database_cleaner, its maintainer will have long fixed it for 2.x, and everyone who has been using it throughout 1.9 will stay with it.

But that's not reason enough for you to change your path, obviously, I was just making that observation. Now's the time where you say, "Well just fork it!"...and I just might when I get some time...just wanted to get a quick understanding of what the scope and need was. Thanks for writing the library! :)

[wideopenspaces]

Personally, I was testing it for use on a company application that is stuck - for now - on 1.9.x - although we are working on a 2.0 migration. If it provides a nice speedup on 2.0 we'll probably use it then. I don't necessarily think there's a need to back-port it.

If I get really antsy, maybe I'll try my hand at it in a fork. :)

[amatsuda]

I hope there's nobody still using ruby 1.x.