ns_func_cleanup branch, notes

Chris Fields cjfields at illinois.edu
Fri Jun 18 15:03:50 UTC 2010


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 <doughera at lafayette.edu> 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              doughera at lafayette.edu
>> 
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev



More information about the parrot-dev mailing list