[TODO] Migrate non-essential PMCs to dynpmcs

[allison]

Several PMCs that are currently compiled as core could (and likely should) be dynamic PMCs instead. Candidates include: AddrRegistry, CodeString, Env, Eval, File, OS, PCCMETHOD_Test, StringHandle, and Timer.

[pmichaud]

The CodeString PMC is used extensively by PGE and PCT to generate PIR output. There wouldn't seem to be much advantage to making it into a dynpmc.

Similarly, Eval PMCs are the result of compiling PIR to bytecode, so I suspect those should stick around as well.

Lastly, I would think that almost every language will end up using the Env PMC in order to access environment variables. It also wouldn't surprise me if PCT::HLLCompiler ends up probing the environment in places.

Pm

[coke]

Allison, do you have any input on Patrick's objections here?

[allison]

Go ahead and move Env to dynpmc (it's used, but not frequently, and the dynpmcs are still core).

There's not really any advantage to having CodeString as a core PMC. Would make more sense as a PIR class (PCT::CodeString or something like that).

Keep Eval for now (ignore it when closing the ticket), but the result of compiling a string should be a Sub object or a Packfile object, not an Eval. I've opened a separate ticket (TT #905) about deprecating Eval, as it should be removed entirely, not moved to a dynpmc.

[pmichaud]

There's not really any advantage to having CodeString as a core PMC. Would make more sense as a PIR class (PCT::CodeString or something like that).

Originally CodeString was a PIR class. We moved it to being a core PMC because it's primary method (emit) is significantly faster written in C than in PIR, and this directly affects compilation speed.

I'd prefer to see that remain the case. Or if we would be better served by creating an 'emit' opcode (that could do the work in C), I'd be okay with that.

If Parrot supports a StringBuffer type that would work as a replacement, we might be able to use that.

Pm

[coke]

Replying to pmichaud:

There's not really any advantage to having CodeString as a core PMC. Would make more sense as a PIR class (PCT::CodeString or something like that).

Originally CodeString was a PIR class. We moved it to being a core PMC because it's primary method (emit) is significantly faster written in C than in PIR, and this directly affects compilation speed. I'd prefer to see that remain the case. Or if we would be better served by creating an 'emit' opcode (that could do the work in C), I'd be okay with that. If Parrot supports a StringBuffer type that would work as a replacement, we might be able to use that. Pm

FYI, The CodeString in branches/codestring now basically uses a StringBuffer under the covers; .emit() adds chunks (doing the substitution), while the get_string VTABLE collapses it into a String.

[coke]

The original list was AddrRegistry, CodeString, Env, Eval, File, OS, PCCMETHOD_Test, StringHandle, and Timer.

PCCMETHOD_Test is already moved.

CodeString & Env were both questioned as to whether or not they should be moved.

Eval is now referenced in other tickets.

That leaves the following as safe to move.

AddrRegistry
File
OS,
StringHandle
Timer

[chromatic]

On Monday 03 May 2010 at 12:38, Parrot  wrote:

>  That leaves the following as safe to move.
> 
>  {{{
>  AddrRegistry
>  File
>  OS,
>  StringHandle
>  Timer
>  }}}

AddrRegistry is *not* safe to remove.  It's part of the root set.  Please 
remove it from the list.

-- c

[coke]

Note that Timer is used by src/scheduler.c and the Scheduler PMC; StringHandle is used by src/io/api.c.

That leaves only File and OS.

[coke]

Replying to coke:

Note that Timer is used by src/scheduler.c and the Scheduler PMC; StringHandle is used by src/io/api.c. That leaves only File and OS.

Which were converted in r46259. Resolving ticket.

If you feel strongly that any of the other items on here should be Dynamic PMCs, you have until 2.6.0's release to re-open this ticket and re-add the deprecation notice. This only covers items in the original list. After that release, a new ticket will be needed.