Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>>
>> At 11:06 AM +0200 8/8/03, Leopold Toetsch wrote:
>[snip]
>> >PMC methods
>> >-----------
>> >ParrotIO has methods via find_method/invoke. Should that be a general
>> >mechanism in default.pmc with one vtable slot for the meth hash?
>>
>> We're going to want lexially nested method caches, so I don't think
>> we're going to want to do this. The method hash needs to be living in
>> the interpreter struct, alas.
> There's no reason why the find_method in default.pmc can't do lookups in
> the interpreter struct, and then of course the normal method would be to
> use find_method.
ParrotIO's methods are hard wired functions implemented in C and called
via our NCI mechanism. So the question is, if we should generalize this
scheme. From pmc/io.t:
set S5, "ok\n"
getstdout P5
find_method P0, P5, "puts"
invoke
end
> This way, if a pmc class wants to override the normal find_method, it
> can.
> For example, PerlObject's find_method could be:
> PMC * find_method(STRING *name) {
> PMC * perlclass = SELF.getprop(string_from_cstring("class"));
> return VTABLE_find_method(INTERP, perlclass, name);
> }
This looks like:
s/perl/python/g; s/class/__class__/;
Anyway, that's up to ParrotClass/ParrotObject. I was thinking of a low
level C<find_method> for all PMCs, with (probably) hard wired methods
like C<isa()>. And these methods should probably not pollute the property
namespace.
> (Hmm, I think that default.pmc would smaller, and no less clear if we
> defined a macro:
> #define THROW_ILL_INHERIT(METH) \
> internal_exception(ILL_INHERIT, \
> "METH" "() not implemented in class '%s'\n", \
> caller(INTERP, SELF))
> And then use
> THROW_ILL_INHERIT(get_number_keyed);
Yep. Actually I'd like to have these autogenerated for all functions
that now throw an exception. We have a list of functions in vtable.tbl,
so classes/pmc2c.pl could provide the function body, if there is none.
default.pmc then would only have functions bodies with "real"
functionality.
Patches welcome.
[ snip ]
> That's why encapsulation is so important. If we had a vtable->isa
> method, then it could be overridden however we want.
We have C<can> and C<does>, yep C<isa> seems to be missing.
leo
