httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: switching t_cmp() argument order
Date Thu, 10 Jun 2004 13:05:14 GMT
Geoffrey Young wrote:
> 
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message