Re: feature-class compiletime memory leak and SAVEDESTRUCTOR

On Mon, Mar 20, 2023 at 06:05:15PM +0000, Paul "LeoNerd" Evans wrote:
> This is one of those "I want to do A so I can do B so I can solve bug
> C" situations; the story is a little long-winded so I'll give a brief
> overview and then dive into detail. Maybe someone can point out a
> better approach?

[ disclaimer: I still haven't read up properly on the class syntax nor how
it's implemented, so the following my be totally missing the point, but
here goes...]

The whole 'deferred compilation' thing sets off lots of alarm bells in my
head. It sounds complex and open to confusing edge cases, as this thread
shows.

Why can't a class declaration be treated just as a block- or file-scoped
sub declaration with some funny special behaviours. So for example,

    class Foo {
        field $x = do { stuff x };
        field $y = do { stuff y };
        method foo { ...; }
        ...
    }

is treated by the lexer and parser as something akin to

    sub Foo {
        do { stuff x };
        do { stuff y };
        sub foo { .... }
        ...
    }

so the do's accumulate in a special CV associated with the class,
while every time a method is seen, a start_subparse() is done, the
method is compiled in its own CV, then PL_compcv reverts to the 'special'
CV and processing the class declaration continues.

On end of block / EOF / new class declaration as appropriate, the
special CV is finished off.



-- 
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
        (with apologies to William Blake)

• feature-class compiletime memory leak and SAVEDESTRUCTOR by Paul "LeoNerd" Evans
• Re: feature-class compiletime memory leak and SAVEDESTRUCTOR by Dave Mitchell