However, I think it's wrong to use the DOD reference counting system for a
couple of reasons
1: The Perl refcounting API lets you get (and set) the actual refcount value.
Whilst I'm quite happy to refuse to support general purpose setting it, I
suspect that getting it is still needed. Certainly it's needed in the
interim for code migration
2: Code should care about the reference count. (Although I believe that some
does). I'd not like to (ask to) extend parrot's DOD registration API to
get the reference count out, because that opens it up to (ab)use by parrot
extensions. The DOD reference count is "none of your business"
3: I think I might need the ability to iterate over all the allocated Ponie
So I think what I'd like is a PMC that provides the same functionality as
dod_register_pmc in pmc.c [see http://svn.perl.org/parrot/trunk/src/pmc.c ]
wrapped into a regular PMC. Basically it provides a hash keyed on addresses,
value is a reference count, where the key/value pair is automatically deleted
if the reference count drops to 0. Only it is (in effect) a singleton.
I'd like to be able to provide this as a non-singleton PMC class, with the
addition of a value lookup, and (possibly) iteration. But cut and paste is
evil. So does anyone have suggestions on the best way to be able to
refactor the code in pmc.c such that it can provide a (private) API for a
core PMC to wrap, without slowing down the DOD's use of the same code.
Does this seem sane? Can anyone see a good way of doing this?
> I'd like to be able to provide this as a non-singleton PMC class, with the
> addition of a value lookup, and (possibly) iteration. But cut and paste is
Well, the more general question is: how can we parameterize our
aggregates. We already have tons of arrays with (bit, double, int, PMC*,
For hashes it could get worse:
key / value
STRING* / PMC* Hash
PMC * / PMC * Python / Perl6
&PMC / INTVAL ref hash
x y Perl6
The hash functions in src/hash.c can handle this (probably), with
key/value type and with user defined compare/hash functions already
We need an interface above that constructs appropriate vtable pieces for
key and value access from the PMC side.
> Nicholas Clark
For now c&p helps :-)
> For now c&p helps :-)
I don't agree. c&p is evil, because it causes code bloat and propagates bugs.
And I'm not after parameterising the aggregates - I'd like to instantiate
another instance of what is currently a singleton, for the same type, with
the same specific, specialised behaviour.
>> For now c&p helps :-)
> I don't agree. c&p is evil, because it causes code bloat and
> propagates bugs.
> And I'm not after parameterising the aggregates - I'd like to
> another instance of what is currently a singleton, for the same type,
> the same specific, specialised behaviour.
Well, with c&p I ment, you have to create a new PMC type, with mostly
c&p code from e.g. the registry hash, then we can instantiate one of
these for the registry and you can use them as well.
> Nicholas Clark