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.
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);
}
Then, PerlClass's find_method might be something like:
PMC * find_method(PMC *key, STRING *name) {
PMC * classname = SELF.get_string();
PMC * lookup = scratchpad_get_current(INTERP);
PMC * method = NULL;
{
STRING * lex_name = string_from_cstring(INTERP, "&", 1);
string_append(INTERP, lex_name, classname);
string_append(INTERP, lex_name,
string_from_cstring(INTERP, "::", 2));
string_append(INTERP, lex_name, name);
method = scratchpad_get(INTERP, lookup, lex_name, 0);
if( method ) return method;
}
lookup = SELF.getprop(string_from_cstring(INTERP, "methods"));
method = VTABLE_get_pmc_keyed_string(INTERP, lookup, name);
if( method ) return method;
lookup = SELF.getprop(string_from_cstring(INTERP, "parent"));
if( !lookup ) return NULL;
return VTABLE_find_method(INTERP, lookup, name);
}
> >Exceptions
> >----------
> >I presume internal_exception() should throw a real exception. So the
> >exception reason should be classified (severity/reason).
>
> Yep. Internal exceptions are generally pretty severe, but they
> certainly aren't all that bad.
Indeed -- consider how default.pmc throws ILL_INHERIT all over the
place... those could be caught.
(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);
Instead of the more verbose code that's currently there.)
[snip]
> >Vtables 2
> >---------
> >Are there any design hints on var/value split of vtables?
> >Currently in a lot of places the address of the vtable is used to
> >check if a class is e.g. a PerlInt. This will not work if that is a
> >tied PerlInt. Other checks are done with vtable->base_type, but a tied
> >PerlInt will have a different class enum too.
That's why encapsulation is so important. If we had a vtable->isa
method, then it could be overridden however we want.
> >So how will we check for "some PerlInt" class?
> >What is the subtype? And what are int_type, float_type, num_type,
> >string_type in the vtable?
>
> I'm still working on these, and as part of it I'm trying to come up
> with a good way to allow layered vtables that aren't horribly
> expensive in terms of memory and time.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
