On 5/17/07, Mehmet Yavuz Selim Soyturk <[EMAIL PROTECTED]> wrote:
On 5/17/07, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> Mmmm, is string_compare a wrapper for strcmp() ? Or is it a wrapper that
> reverses the result? (so return true if they're equal). In /that/ case,
> !string_compare() would be nicer. (my point being, if string_compare() is
> part of parrot source code, why not try and make it more sensible/readable).
> (I understand why the result values are the way they are for strcmp, but i
> never liked them)
>
> kjs
I think that it's analogous to strcmp, but for the STRING* type. I
looked now at string_funcs.h, there is in fact a string_equal
function.
there's a few locations where i think string compares can be cleaned
up. this is one case, where the '== 0' syntax is a bit ugly. another
is src/pmc/class.pmc (and others), where there's a bunch of
comparisons to a set of constant c strings, which look like:
else if (string_equal(interp, what, CONST_STRING(interp,
"namespace")) == 0) {
but could probably be shortened to something like:
else if (string_equals_const_c_string(interp, what, "namespace")) {
if something like C<string_equals_const_c_string> is implemented.
By the way, that wasn't the only issue. PCCRETURN expands to multiple
statements, so the curly braces are needed after the if test. Would it
not be better if PCCRETURN did it itself?
i'm working on a patch to modify the PCC docs to note that PCC*
expands to a statement list, so when used inside a selection statement
(if, while, etc) PCC* requires a block. i'm also looking over the
current code to see if there are any other violations of this rule.
however, your suggestion to have the PCC expansions automatically
enclose themselves in blocks is interesting, and merits
investigation--i'll take a look at that, too.
~jerry
