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