chromatic wrote:
PARROT_API
PMC *
key_next(SHIM_INTERP, PMC *key /*NN*/)
{
return key->pmc_ext ? (PMC *)PMC_data(key) : NULL;
}
Is this in need of fixing? If so, how? If not, is there a better
function to show off what needs fixing?
This isn't a great example, as the guts of hashes and keys and iterators are
all over various files instead of nicely encapsulated in .pmc files.
It's a great example, but of a different problem. Namely, those guts
should be moved into the .pmc files.
A really simple example of the kind of refactor that needs to happen is
one in the code I'm working on for objects. In src/pmc.c in the
'pmc_type' function, there's a section that retrieves a class entry from
the classname_hash, then calls:
return PMC_int_val((PMC*) item);
to get the integer value from the class entry PMC. What it should call is:
return VTABLE_get_integer(interp, item);
Both return the same answer, but the second doesn't break the
encapsulation boundary. (The second also doesn't depend on data being
stored in the PMC's struct union cache, which is a definite plus if we
deprecate that storage slot.)
Allison
