Instantiating objects
Dan Sugalski
single-inheritance objects up and running.
At the moment, I'm torn between just having a new method of some sort in
the class and having a vtable method on the class PMC that returns an
object of that class. (get_pmc on the class returns a new object, or
something of the sort)
I'm open to suggestions here...
Dan
Leopold Toetsch
While get_pmc is totally unused the name is probably misleading. It
accompanies set_pmc, which is basically C<assign>. When I'm thinking of
get_pmc, ties and refs come to my mind (that get the PMC they are
referring to), but no new objects.
So probably a new vtable would be better. Or alternatively:
(If you didn't think of the same above :)
You put it into the find_method/callmeth scheme that we already have
(and use in parrotio.pmc) for PMCs.
That would mean: on class_init all (instantiable) PMCs get a NEW method
(maybe inherited from default.pmc) which does pmc_new()/init() on the PMC
class, which for parrotclasses does the Right Thing.
This is one extra lookup for the NEW method, but could be useful for
ultimate flexibility.
s. classes/{parrotio,default}.pmc and t/pmc/io.t for the method stuff.
> Dan
leo
Jeff Clites
What do you mean by "new method in the class" above?
To use the vocabulary of other languages, if you're trying to decide
between a static method (a.k.a. a class method), versus a instance
method on the class object, I'd say they amount to the same thing.
(Either involves calling an implementation which depends on the class,
and arranging for that implementation to have access to class-specific
data, in the form of a class object or static class data.) Here the
distinction is mostly just a matter of viewpoint--C++ has static
methods, ObjC has class objects.
If you're trying to decide whether the creation method should have
access to a class object, then I think it should--that makes it easier
to implement things such as singletons, since you have a place to hang
state, such as a cache. And calling this an instance method on the
class object is conceptually simpler (I would argue).
Or did I totally miss your point?
JEff
Dan Sugalski
> On Oct 15, 2003, at 8:36 AM, Dan Sugalski wrote:
>
> > I'm poking around in the object stuff today, to try and get at least
> > single-inheritance objects up and running.
> >
> > At the moment, I'm torn between just having a new method of some sort
> > in
> > the class and having a vtable method on the class PMC that returns an
> > object of that class. (get_pmc on the class returns a new object, or
> > something of the sort)
>
> What do you mean by "new method in the class" above?
In this case, the "new method" is a named method in the class namespace
that we look up and call. We'd look it up and dispatch to it.
The vtable method, on the other hand, would be a function in the vtable
that we'd dispatch to like any other vtable method. It'd be a class
method, as we don't really have object methods as such. (I think, hard to
say, the terminology escapes me at the moment)
Personally, of the two I prefer a vtable entry, as it's a lot faster.
The third option is an instantiate op that has access to Deep Internal
Knowledge about classes and objects and does all sorts of Nasty Evil
Things to build the object from the class.
Having said that, the bytecode itself would be blissfully ignorant of any
evil, since to instantiate an object for the Foo class, you'd call:
getclass P1, "Foo"
instantiate P4, P1
At least I think we would. I can see making this:
find_type I4, "Foo"
new P4, I4
instead, basically eliminating the differences between "objects" and
generic PMCs. I'm not 100% sure I want to do that, though.
> If you're trying to decide whether the creation method should have
> access to a class object
This is a given, as the class object has the information we need to figure
out slot allocation and whatnot. We could find it by name if we wanted to,
but we might as well mandate that it be around.
Dan
Melvin Smith
For some reason I'm getting the feeling that PMCs and "Classes" should
be one and the same. Otherwise it seems we are making Parrot more
complex than it needs to be.
My gut feeling is that everything should be a Class, whether implemented
in the C API or in bytecode, and a PMC vfun should be equivalent to a
class method. That stands for PerlUnder, PerlHash, etc. as well.
If we have class support, native call support and an extension API, I
see no reason why we even need the concept of a PMC.
-Melvin
Jeff Clites
...
>> instead, basically eliminating the differences between "objects" and
>> generic PMCs. I'm not 100% sure I want to do that, though.
...
> For some reason I'm getting the feeling that PMCs and "Classes" should
> be one and the same. Otherwise it seems we are making Parrot more
> complex than it needs to be.
>
> My gut feeling is that everything should be a Class, whether
> implemented
> in the C API or in bytecode, and a PMC vfun should be equivalent to a
> class method. That stands for PerlUnder, PerlHash, etc. as well.
>
> If we have class support, native call support and an extension API, I
> see no reason why we even need the concept of a PMC.
My brain was in PMC == class mode when I wrote what I wrote above, but
now I need to rethink, since that's not a given (yet?). I was probably
thinking that because currently the *.pmc files live in directories
called "classes" and "dynclasses".... (So I was thinking of PMCs as
classes at the parrot implementation level--that is, if Parrot were
written in C++, they'd probably be C++ classes.)
So at the moment I'm a bit fuzzy on the terminology we're using--I
guess there are "classes" and "objects" at the HLL level (the
terminology for which may differ between HLLs), and PMC definitions
(the source code) and instances (the allocated in-memory "thing") at
the parrot level. And I guess a fundamental design choice for parrot is
that a "Perl object" can be treated as an object from Python code (and
vice versa), although this is hard to reconcile (at least
terminologically) with the Perl (Perl 5 at least) notion that
strings/arrays/hashes/etc. aren't considered to be objects, but they
become objects if they are blessed into a class.
Hmm, I need to think this over a bit more....
JEff
Leopold Toetsch
> On Wed, 15 Oct 2003, Jeff Clites wrote:
>> What do you mean by "new method in the class" above?
> In this case, the "new method" is a named method in the class namespace
> that we look up and call. We'd look it up and dispatch to it.
A more low level like POV might be:
newclass P1, "Foo"
... # define attributes
find_method P2, P1, "NEW" # P2 is the "new" method, hash lookup here
instantiate P3, P2 # P3 is a new object
> The vtable method, on the other hand, would be a function in the vtable
> that we'd dispatch to like any other vtable method.
P3 = P1->vtable->instantiate(..)
> ... It'd be a class
> method, as we don't really have object methods as such. (I think, hard to
> say, the terminology escapes me at the moment)
PMC "classes" are basically objects obtained by the pmc_new() function.
The "class" behavior is mostly fixed and done within the PMC compiler.
Then we have the ParrotClass PMC which is such an "object" PMC that,
when instantiated gives "Real Objects" of that class. Tha WRT
terminology :)
> Personally, of the two I prefer a vtable entry, as it's a lot faster.
Its faster, yes. But did you consider using the OrderedHash PMC for such
things. Creating is speed of (hash+array) lookup is either. So for well
known methods the lookup could be just an array index lookup.
> The third option is an instantiate op that has access to Deep Internal
> Knowledge about classes and objects and does all sorts of Nasty Evil
> Things to build the object from the class.
This would probably prohibit all overloading of object construction.
> find_type I4, "Foo"
> new P4, I4
> instead, basically eliminating the differences between "objects" and
> generic PMCs. I'm not 100% sure I want to do that, though.
For now, I'd say:
- generic PMCs don't have definable attributes, they are fixed
- they don't have Parrot Subs as methods and
- the methods they "can" are fixed, hardwired
I think that for supporting Ruby or such we have to keep fences between
PMCs and "real objects" very low. So it should be possible to define an
Imaginary Number class that inherits from two (Perl?)Nums directly and
overloads some operators without much overhead, i.e. the 2 attributes
(re, im) would be kept in the 2 number PMCs.
> Dan
leo
Luke Palmer
> I think that for supporting Ruby or such we have to keep fences between
> PMCs and "real objects" very low.
Agreed, or have some sort of automagic transformation possible.
> So it should be possible to define an Imaginary Number class that
> inherits from two (Perl?)Nums directly and overloads some operators
> without much overhead, i.e. the 2 attributes (re, im) would be kept in
> the 2 number PMCs.
I don't think that would work. If I remember correctly, we're going to
make all inheritance 'virtual', correct? Which means that inheriting
from 2 number PMCs should be precisely the same as inheriting from 1
number PMC.
That's okay, though, because from a design perspective, inheritance
wouldn't be the way to go about that kind of problem anyway :-)
Luke
>
> > Dan
>
> leo
Dan Sugalski
> My brain was in PMC == class mode when I wrote what I wrote above, but
> now I need to rethink, since that's not a given (yet?).
Not a given ever. PMCs may have a backing namespace, and that namespace
may be a HLL class, but it might not.
The terminology (PMC classes vs HLL classes) is definitely confusing, and
unfortunate. We probably ought to have a renaming before we go live.
Dan