On Mon, 15 Jul 2002, Ashley Winters wrote: > PDD02: Common vtable format for all variables > Nice.
I should be able to answer some of these. > Question: Why is the key param for keyed_int vtable functions a pointer? > Considering I have to implement all those functions to add a PMC... > seems odd to be passed a pointer to a value which is guaranteed to be > non-NULL. In some cases they are not guaranteed, but you are right, this is a valid point for a few cases. A little history: they were all originally not pointers. When I realized that you didn't *have* to specify a key for all args of certain ops (namely, those that take multiple PMCs), I made them all pointers (not following the logic through in my head like you did). I suppose they are all pointers now just for consistancy. If that's not a good enough reason (speak now people) then I'll change it for those cases where they will not be NULL. The real kicker is that I'll bet this is going to change in view of the multimethod vtable method non-method methodology that has been discussed recently. > Is every parameter for every vtable function IN? Err, I just found the > add_* functions. Answer: no. For a specification like this, perhaps > in/out could be added to parameters or something? It's loathesome non-C > clutter, I know. You don't have to put it in, I can live without it. :) If there's an output parameter, it's named "dest". That rule holds throughout the vtable spec. > Question: set_string_(native|unicode|other) specifies source or dest > format? I'd assume the string type is the destination's type. It does > coercion from the source STRING*'s format to the $1 format, right? Um, that one I'm not sure about, not being up to speed on strings. I'll get back to you in a few months (years??) :-) If the convention for integers/numbers is followed it would refer to the source, but that really doesn't make sense since the source string's encoding should be able to be determined without help. I would say it is the destination format. > I don't see any mention of thunking /(.*)(_keyed.*)/ functions to > $1(get_pmc$2()). > > Question: Are thunked _keyed methods provided by default for PMC implementors? > vtables.pod says there are 'sensible' defaults, but it seems to have been > written pre-keyed-PMCs. There are defaults for the _keyed(_int)? methods that will throw exceptions if you try to do an aggregate operation on a PMC that "inherits" those defaults. But like I said, expect everything to change with the multimethod stuff coming in. - D <[EMAIL PROTECTED]>
