[svn:parrot] r33417 - trunk/src/pmc

[Patrick R. Michaud]

On Wed, Dec 03, 2008 at 12:14:55PM +0100, NotFound wrote:
> >> +    VTABLE INTVAL is_same(PMC *value) {
> >> +        return PMC_IS_NULL(value);
> >> +    }
> >> +
> >>  }
> >
> > Since there's only one PMCNULL value, do we really need this
> > vtable entry?  And why would it do anything different from the
> > default, which is to compare C<value> and C<SELF> ?
> 
> If we delete it, this is the generated vtable entry for the null pmc:
> ...
> Defaults for the null pmc are not taken from the default pmc, they are
> handled apart.

Ah, excellent.  This makes sense to me.

> > In fact, naively I expect that nearly all PMCs should simply
> > use the default "is_same" VTABLE function, which simply returns
> > the result of C< value == SELF >.  It's not at all clear to me
> > why some of the PMCs override this default behavior.
> 
> This is the explanation in string.pmc POD:
> ------------------------------------------------------------------------
> Returns true if this PMC and the one in C<value> are of the same PMC
> class and their strings are aliases of the same internal string.
> 
> (this can only happen if you use the set_string_native method)
> ------------------------------------------------------------------------
> I don't know the rationale of this intended behavior, nor if there are
> any test for it.

I'm fairly certain there's no test for it, because removing it
doesn't cause any tests to fail.  And I don't see how the intended
behavior is useful or consistent with what I expect is_same to do.

That said, the latest fix in r33452 resolves the issues I was
having -- I've added my test cases as regression tests.

I think we still need a test case for the intended behavior before
we can close trac #11, and I've marked it as such.  I've also given
it a lower priority.

Thanks!

Pm