Ticket #2163 (new RFC)

Opened 3 years ago

Last modified 3 years ago

Reconsider IGLOBALS_PBC_LIBS

Reported by: whiteknight Owned by:
Priority: normal Milestone:
Component: core Version: master
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: all

Description

The global IGLOBALS_PBC_LIBS stores a mapping of file name to full path name for entries loaded with load_bytecode_s (Deprecated in #2146). Since load_bytecode_s can be used to load a .pbc, .pasm, or .pir file, and automatically compiles files if necessary, the mapping key is the filename without the extension.

With the new load_bytecode_p_s op, we can start to redesign this data item. The new op returns a PackfileView PMC when loaded and currently does not cache values. If you do "$P0 = load_bytecode 'foo.pbc'" twice, it will attempt to load the same file twice into two PMCs. I don't know if this is considered a bug, or something we want to keep. After all, it's entirely possible that a .pbc file could change during program execution, and re-loading it will return a packfile with different contents.

If we want to have a cache still, I suggest we repurpose IGLOBALS_PBC_LIBS to map full path name to PackfileView result. The user can, of course, get access to this hash and delete keys from it if she wants to reload it. Then, we can update the new load_bytecode_p_s op to use the repurposed cache.

Similarly, we can deprecate IGLOBALS_PBC_LIBS and replace it with a new cache so that both load_bytecode ops have a cache to use during the deprecation period.

If we do not want Parrot to contain an explicit hash, we can let IGLOBALS_PBC_LIBS be deprecated and removed when load_bytecode_s is. User code can keep track of the libraries they want to load themselves.

Change History

Changed 3 years ago by jkeenan

  • component changed from none to core
Note: See TracTickets for help on using tickets.