Deprecations for 3.0
Peter Lobsinger
plobsing at gmail.com
Fri Sep 17 15:18:41 UTC 2010
On Fri, Sep 17, 2010 at 8:12 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> On Fri, Sep 17, 2010 at 1:54 AM, Peter Lobsinger <plobsing at gmail.com> wrote:
>> GC:
>> * Generational:
>> * requires barriers to handle bookkeeping at reference creation
>> * existing object attribute access barriers are:
>> (a) unwieldy and therefore not used consistently
>> (b) insufficient to support more complicated uses. a good
>> example is PMC aggregates.
>
> I mentioned in #ps, but I don't think that this requires a
> deprecation. The write barriers already exist and are documented on
> their purpose and their uses. What we would be changing is the level
> of enforcement in their use, which doesn't really seem like a
> deprecation policy issue to me. We can add in a note if people want.
So why haven't you used them in either parrot-data-structures or
parrot-linear-algebra?
But more to the point, they are insufficient for handling aggregates.
If a PMC cointaining ATTR isn't a simple PMC*, but something more
complicated (like PMC**), the whole thing falls appart. Clearly you
can still have one PMC reference another by these means, but the
SET_ATTR and GET_ATTR macros cannot express these assignments.
Try rewriting ResizablePMCArray or Hash or PMCMatrix2D or any
aggregate to use them. They don't work in these cases. We need
something more general.
More information about the parrot-dev
mailing list