stevan/p5-mop — Issue #30: Classes, Objects, Typeglobs, Barewords
Author: cpansprout
Created: 2011-12-12 07:42:55+00:00
State: open

In proposal/001-syntax-and-semantics/010-class.pod, you mention that these two are equivalent:

class Foo {}

*Foo = Class->new( name => 'Foo' );

In the current prototype implementation, that is obviously not the case.

Later, under NOTES, you write:
> I wonder if the best way to handle the class barewords would be to add a CLASS slot into the TYPEGLOB? To go along
> with the existing SCALAR, ARRAY, HASH, IO, etc.

If, as you state in proposal/000-mop/000-intro.pod, Class is an instance of Class and Class is a subclass of Object, then it should be an OBJECT slot, shouldn’t it?

So it sounds as though you are suggesting that new mop objects be their own opaque type.

That makes sense, but then it begs the question, how should `Foo->bar` be resolved? Currently, with a bit of simplification we can say that Foo resolves to one of the following, in order of precedence:

• Subroutine
• IO handle
• String / package name

Where would objects go in that list? At the top? After subroutine?

(It also raises the question as to whether we want typeglobs to get any bigger than they already are, but that’s an implementation detail that can be figured out later.)

(On the other hand, it’s pretty big and one more pointer wouldn’t make much of a difference:

```C
struct gp {
SV *	gp_sv;	/* scalar value */
struct io *	gp_io;	/* filehandle value */
CV *	gp_cv;	/* subroutine value */
U32	gp_cvgen;	/* generational validity of cached gv_cv */
U32	gp_refcnt;	/* how many globs point to this? */
HV *	gp_hv;	/* hash value */
AV *	gp_av;	/* array value */
CV *	gp_form;	/* format value */
GV *	gp_egv;	/* effective gv, if *glob */
line_t	gp_line;	/* line first declared at (for -w) */
HEK *	gp_file_hek;	/* file first declared in (for -w) */
};
```

)