MMD & objects
Dan Sugalski
deal with are:
*) Inherited methods
*) Objects
The big issue with inherited methods is how we treat parents of PMC
classes, since they're both on a separate inheritance tree and also
feel like they've got a very different weight to them than standard
object-type inheritance. On the other hand, if we decide it isn't
really inheritance at all, rather just layered defaults, the problem
just goes away and that's fine too. Either way we need to build up
the tables so inherited MMD methods actually get inherited.
MMD for objects is a different thing entirely. Right now we have it
set up such that you *must* explicitly declare each MMD
method--there's nothing automatic (though there's a lot of
behind-the-scenes defaulting with PMCs) about how it works. Which is
fine, but if we do that we need to decide what level of HLL support
we want to give for getting MMD methods into the table in the first
place.
Other than that (and the first issue's been one all along) we're in
pretty good shape, and about where we were before we did the MMD
switchover.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> The basics of MMD are almost done. The two things we still need to
> deal with are:
> *) Inherited methods
> *) Objects
> ... Either way we need to build up
> the tables so inherited MMD methods actually get inherited.
MMD registration "inherits" as much as vtables did. E.g. PerlInt
registers MMD functions from 3 different classes.
leo
Dan Sugalski
Yes, I know this Leo--I spent a good chunk of Saturday fiddling
around inside these things. :)
The question isn't whether they *do*--rather it's whether they
*should*. The current implementation's not all that relevant except
as a demonstration of one set of semantics. What I want to do is work
out what the 'proper' semantics ultimately should be.
Leopold Toetsch
> The question isn't whether they *do*--rather it's whether they
> *should*. The current implementation's not all that relevant except
> as a demonstration of one set of semantics. What I want to do is work
> out what the 'proper' semantics ultimately should be.
I think that the static "inheritance" inside classes/ is ok. We have to
rearrange classes hierarchy, though. The special MMD based Integer and
Float classes are no more special, array classes still need finishing.
A nice to have would be a more sophisticated MI scheme. It's ok inside
the PMC files, e.g. from orderedhash.pmc:
void mark () {
SUPER();
PerlHash.SUPER();
}
but the build dependencies are created manually.
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>
>> The question isn't whether they *do*--rather it's whether they
>> *should*. The current implementation's not all that relevant except
>> as a demonstration of one set of semantics. What I want to do is work
>> out what the 'proper' semantics ultimately should be.
>
>I think that the static "inheritance" inside classes/ is ok. We have to
>rearrange classes hierarchy, though. The special MMD based Integer and
>Float classes are no more special, array classes still need finishing.
If we do that it means every PMC class is essentially a base type as
far as Parrot's concerned.
Which, on reflection, I'm just fine with. So let's do that. I'll
patch up the float and integer classes while I'm at it too.
Leopold Toetsch
> If we do that it means every PMC class is essentially a base type as
> far as Parrot's concerned.
Basically yes. We just borrow some functions from parents to avoid
reimplementation and to reduce code size. I don't think that we need
much more inside the core classes. We could save some more code with a
bit of MI but I dont't think that it's worth the effort.
BTW: the current "class" hierarchy can always be obtained by:
$ perl classes/pmc2c2.pl --tree classes/*.pmc
> Which, on reflection, I'm just fine with. So let's do that. I'll
> patch up the float and integer classes while I'm at it too.
These two classes could inherit from C<scalar> now, which implements a
lot of basic functionality. C<mmd_default.pmc> can be tossed already
AFAIK.
Then we can start figuring out how to calculate object MMD distances and
how to properly dispatch delegate.pmc :)
leo