Ticket #789 (closed todo: wontfix)

Opened 5 years ago

Last modified 3 years ago

Make All PMCs Subclassable

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

Description (last modified by Infinoid) (diff)

Several core PMC types are not subclassable because they have attributes that are not the "register" types (P, S, N, I). What happens is that the subclass operation acts like normal, but Objects of the resultant class are not usable for normal operations.

Some examples:

  • FileHandle (see #681)
  • ExceptionHandler (See #154)

Any other PMC type that uses a non-subclassable ATTR will have the same problem, although to my knowledge no tickets for these have been opened yet.

I had been working in #681 in a branch, but after talking with Allison we decided that the approach had the right idea but the wrong implementation.

From IRC today (paraphrased):

allison> give PIR Classes the ability to create a delegate or proxy structure for ATTRs that aren't register types
allison> the basic problem is, attributes in PIR Classes are stored in an array
allison> That array can only have PMC elements
allison> so, it knows how to box and unbox the basic register types
whiteknight> so do something like box C types into ManagedStruct or something similar?
allison> the best place to start is probably with a list of C types in the current C PMCs, and how they can be represented as a PMC

See the whole discussion here:  http://irclog.perlgeek.de/parrot/2009-06-24#i_1263385

So here's a quick list of tasks that we can do to fix this problem:

  • Get a list together of all ATTRs in built-in PMC types that are not INTVAL, FLOATVAL, STRING* or PMC*
  • Determine how to store each of those types in PMCs. This could mean using ManagedStruct or UnmanagedStruct, Pointer, CPointer, or some new type entirely
  • Teach the GETATTR/SETATTR macros how to access values that are boxed like this.

This whole process probably requires a little bit more thought and planning, I'll try to create a page on the wiki somewhere so that we can plan this in more detail.

Change History

follow-up: ↓ 3   Changed 5 years ago by whiteknight

Here is a quick list of alternate types that appear in ATTR declarations:

void*
Parrot_Interp
struct parrot_interp_t *
char*
Parrot_mutex
UINTVAL
(various function pointers)
Parrot_Context
Hash *
PIOHANDLE
STRING**
PMC**
INTVAL* 
FLOATVAL*
unsigned char*
size_t
PIOOFF_T
BIGINT*
BIGNUM*
struct Parrot_cont *

  Changed 5 years ago by Infinoid

  • description modified (diff)

in reply to: ↑ 1   Changed 5 years ago by Infinoid

Replying to whiteknight:

> STRING**
> PMC**

For those two, my first thought was to use FixedStringArray and FixedPMCArray. But FSA and FPA are the only places where those ATTRs appear, anyway, so you might as well just return the "self" pointer. Does reboxing them serve any purpose? (And does this mean FSA and FPA have the same subclassability issue?)

Mark

  Changed 5 years ago by Infinoid

Along the same lines, PIOHANDLE could be autoboxed into INTVAL or Pointer, depending on platform. I think. Is that the plan?

  Changed 5 years ago by jkeenan

  • component changed from none to core

  Changed 5 years ago by chromatic

  • milestone changed from 2.0 to 2.1

follow-up: ↓ 9   Changed 5 years ago by allison

  • milestone changed from 2.2 to 2.4

Non-register typed attributes are one problem, other problems with subclassing seem to be involved with PMCProxy. Review HLL's needs.

  Changed 5 years ago by gerd

  • milestone changed from 2.4 to 2.5

in reply to: ↑ 7   Changed 4 years ago by jkeenan

Replying to allison:

Non-register typed attributes are one problem, other problems with subclassing seem to be involved with PMCProxy. Review HLL's needs.

Okay, so how do we go about reviewing the needs of the different HLLs?

  Changed 4 years ago by gerd

  • milestone changed from 2.5 to 2.10

  Changed 4 years ago by whiteknight

  • owner set to whiteknight

  Changed 3 years ago by whiteknight

  • priority changed from normal to blocker
  • platform set to all
  • version changed from 1.3.0 to master
  • status changed from new to assigned
  • milestone 2.10 deleted

We're planning for some major changes to our object model system in the coming months with both 6model and Lorito on the horizon. I do not suspect that 6model is going to magically fix this issue, but it will give us a new landscape to work on. I suspect that things like the new StructView and Ptr PMCs will make this work much easier when it's time to attempt it. For now, until 6model is in Parrot, this ticket is on hold.

  Changed 3 years ago by whiteknight

  • status changed from assigned to closed
  • resolution set to wontfix

I'm closing this ticket. Making all PMCs subclassable in the way that this ticket suggests in an interesting goal but not one that we are actively pursuing. Notice that this might happen automatically after such initiatives as 6model and M0, so no sense pursuing this separately. It's very possible that, following 6model integration, that there is no difference between and Object and a PMC, which would make this ticket moot.

I'm closing this ticket. It's not something that we are going to specifically pursue, but we might achieve the goal anyway in later projects.

Note: See TracTickets for help on using tickets.