Stas Bekman wrote:
Geoffrey Young wrote:
But it's quite possible that argument could be readonly while not a string, a simple example is a return value of a function:
% perl -le 'a(b(), "b"); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \ sub b { 5 }' Modification of a read-only value attempted at -e line 1.
I think you need to revisit that example :)
I fail to see what do you mean.
perl -le 'a(b(), c()); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \ sub b{5}; sub c{6};
I still don't get it. What are you trying to say?
ok, the attached patch reflects that.
excellent!
the only remaining nit is the deprecation cycle, let's say we happen to release the next few versions within this month, then you hit 1.15 really soon. I think it's a matter of time and not release numbers. So may be it's better to say, let's give people some 3 months to move over and set a certain date as a cutoff rather than a version number? Just an idea...
sure, we could do that, but then the cutoff isn't really clear. I think that three revisions will get us through at least another mod_perl release, when people are perhaps likely to glance at the Changes file.
but if we need more time I think we can take it. if the deprecation cycle is very long (like 3 new releases takes us a year) I don't think that's necessarily a bad thing.
Not for Apache-Test. There will be lots of new mp2 releases in the next few months to come. Once the API is completed and a few remaining release issues resolved we will start doing release candidates. So as long as we do at least one tweak to A-T between these releases I promise you A-T 1.15 before the end of the summer.
but either way is fine. I just didn't want it removed in, say, the release after the next one.
just add a line like, remove after Sep 15th or so. and may be take it into if ($deprecated) { ...} so it's easy to remove the whole branch at once without thinking too much.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
