ok for the first thing that matches the signature in all cases,
rather than having logic that checks to see if it needs to invoke the
multimethod logic ... I guess it might slowdown if the override is handled
as a multimethod that goes to the new or callst he next level's multi,
instead of sucking it down and collapsing it for one giant multi ...
--attriel
he refcount ... I think that's compiler level, so
it just takes longer to compile, while it tosses in the extra opcodes for
decrements ...
and then if the refcount == 0 we just mark it for GC and forget about it
entirely ...
Like i said, no idea how all that ACTUALLY works out in parrot, though :o
--attriel
d then calling P is no longer "legitimate" ... But
I'm not entirely convinced that's not the coder's problem, since that
would, imo, be a side-effect of whatever calls were made between "can" and
"call", which means either (a) they're documented prop
ram-info incurs ...
Short version: I think both are good. Yes/No is inferrable from a
pointer, but if the pointer has to include other information (and thus be
a full PMC or however, precisely) seperate might be good.
--attriel
gle-MI structure that dan proposed? as in, if B inherits from
A and then C inherits from A and B directly (and assuming there's a need
to separately retain the individual inheritance directions), wouldn't the
compiler then say that B inherits from A and C inherits from A2 and B, to
retain
..
>
> Why would we want to avoid this? It looks exactly like what ought to
> happen.
I think he was explaining what he meant in another post that someone
questioned, with this example; then the "wants to avoid this" referred to
"avoiding the easy-path error of NOT doing this". I think Gopal was
saying that C#/NET does it that way, and I can't imagine him asking to
have functionality he explicitly needs to be "carefully avoided" :)
OTOH, I may have misread a bunch of things, I'm not doing so hot on my
interpretations the last few days :o
--attriel
