One thing a project I'm working on does with deprecations is to map these
accordingly, but call a method that checks the currently-running version
against an indicated deprecated version. This prevents us from losing
deprecated methods in the tons of code we have if we don't add warnings. Of
course, this is in perl, but it's something like:
sub old {
my ($self) = shift;
$self->deprecated(-warn => '1.6', -throw => '1.7');
$self->new_method(@_);
}
That way, when the version number advances you will get proper messaging. I
think there may even be an option for a message that indicates what the dev can
do to update.
chris
On Jun 18, 2010, at 9:55 AM, Andrew Whitworth wrote:
> Yes, that's a very good thought. Keeping wrappers around would be a
> good thing for groups like Rakudo that need them. I will try to add
> these tonight. These kinds of points would be very well to explicitly
> include in whatever new deprecation policies or processes that we
> adopt.
>
> --Andrew Whitworth
>
>
>
> On Fri, Jun 18, 2010 at 10:46 AM, Andy Dougherty <[email protected]>
> wrote:
>> On Thu, 17 Jun 2010, Andrew Whitworth wrote:
>>
>>> I just merged the ns_func_cleanup branch into trunk. To recap:
>>>
>>> First part of the branch is renaming functions to follow proper naming
>>> conventions, and in some cases to be more accurate/descriptive about
>>> what they do:
>>> Parrot_get_namespace_keyed* -> Parrot_ns_get_namespace_keyed*
>> [ ... more similar sensible renamings ... ]
>>
>>> I'm going to start putting together a patch for Rakudo now, and maybe
>>> partcl too, if I have time tonight (tomorrow otherwise). If anybody
>>> else needs help with the update, let me know.
>>
>> I just read this mail and the "backward compatibility" mail thread in one
>> sitting, and had the following thought:
>>
>> This, of course, breaks Rakudo, and any other HLL using those functions,
>> and even though you are kindly fixing those, it will still make bisecting
>> around this change difficult.
>>
>> Would it be sensible to keep the old names around for a while as mere
>> wrapper functions for the new ones? Of course Rakudo could stick in a
>> bunch of #ifdefs to deal with the change, but I think the technical burden
>> should be parrot's in such things.
>>
>> --
>> Andy Dougherty [email protected]
>>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
