second string refactor landed

[Patrick R. Michaud]

On Tue, Feb 03, 2009 at 12:31:17AM -0800, Allison Randal wrote:
> I merged in the second half of the string refactors in r36319, an API  
> function renaming to match the Parrot coding standards and the  
> specification in PDD 28.

Can we PLEASE PLEASE PLEASE use this as an opportunity to
fix the naming and/or semantics of string_equal 
(now Parrot_str_equal)?

Previously the C<string_equal> function (and now C<Parrot_str_equal> )
returns zero (i.e., false) if the two arguments are *NOT* equal, 
which makes for some very confusing code.  Let's not propagate or
sanctify this any further than it already exists.

I recognize that it's not simple to go update the logic for all
of the calls to string_equal, but if we're global-search-and-replacing
the function name anyway, let's at least change it to 
Parrot_str_not_equal so that the boolean result matches what
is actually being tested.

> I made the function name substitutions on all languages in the Parrot  
> repository. For languages outside the repository, I've attached a file  
> of all the name changes (conveniently, it happens to also be a Perl  
> script you can run to update all function names on a list of files).

Should we take this as an indication that Parrot will be playing
a little looser with the deprecation guidelines between now 
and 1.0?  AFAICT it wasn't mentioned in DEPRECATED.pod, nor any of the
#parrotsketch meetings (apologies if it was and I missed it).

Pm