Excellent idea. Actually I hate adding more complexity and more bugs just for sake of backward compatibility, but a bit of compatibility doesn't hurt either. Especially if it can be compile time option or some such, so when you don't need it, you just flip the (make) switch and voila.

PS I'm hoping to move my 30+ (smallish) embperl site to v2 and report problems as they come, but unfortunately, Embperl 2 deosn't run on either on out systems :-( (Honza Kynzl already reported it)

- Robert


Neil Gunton wrote:


Here's an idea: There seem to be two kinds of changes that have to be
made to existing 1.x code in order to transition to 2.x. The first kind
are changes which would still work under 1.x (for example putting
brackets around the expression in [$ foreach $], or making [+ do { } +]
for expressions which had more than one statement). Obviously those are
changes that I am ok with making, because although they are necessary
for 2.x, they won't break my site under 1.x. The other kind of change is
the more worrying one - where I have to change the code in a way that
breaks 1.x, e.g. the way I reference certain objects or methods. To take
just one example, in my current site I call $req_rec->update_mtime() to
set the modification time for the page, whereas in 2.x you have to have
something like $req->apache_req->update_mtime(). This is different
enough that it's worrying to go through all your code changing it,
knowing that you'll just have to roll back if 2.x breaks for some
reason.

So here's the question for Gerald: How hard would it be to include
"compatibility" objects and methods so that code will work under both
1.x and 2.x? So I could count on, for example, $req_rec being there in
either version? I have no idea how many other little instances of this
there would be, but it's just an idea. It would certainly make testing
2.x much easier for people like me who already have large "production"
installations of Embperl and need to test 2.x. without converting all
their code immediately. I think anyone like me would be a little
cautious about changing all their code to test 2.x, and then having to
either change it all back again to go back to 1.x, or else develop some
kind of complex merge that would quickly get out of date as new
development is done.








--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to