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};
>
>> 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.
but either way is fine. I just didn't want it removed in, say, the release
after the next one.
--Geoff
