On Fri, Jun 25, 2004 at 09:46:53AM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > I've just fallen into this trap, and I doubt I'll be the last one:
>
> > void Parrot_PMC_set_intval_intkey(Parrot_INTERP interp, Parrot_PMC pmc, Parrot_Int
> > value, Parrot_Int key) {
> > VTABLE_set_integer_keyed_int(interp, pmc, key, value);
> >}
>
> > Is there any reason why the vtable is key, value but the extension
> > interface is value, key? This parameter transposition strikes me as
> > asking for trouble.
>
> It seems order was chosen according to function name (_intval _intkey).
>
> > I'll patch everything in core to make value last if consensus is that
> > this is the right thing to do.
>
> Yep. I'd swap function names as well as argument order, so that
> everything matches the vtable prototype.
I'm not sure that swapping all the function names is great. The vtable
currently has entries such as
INTVAL get_integer()
INTVAL get_integer_keyed(PMC* key)
INTVAL get_integer_keyed_int(INTVAL key)
INTVAL get_integer_keyed_str(STRING* key)
void set_integer_native(INTVAL value)
void set_integer_same(PMC* value)
void set_integer_keyed(PMC* key, INTVAL value)
void set_integer_keyed_int(INTVAL key, INTVAL value)
void set_integer_keyed_str(STRING* key, INTVAL value)
^key type
^variant
^slot type
^action
and the rename change would turn
void Parrot_PMC_set_intval_intkey(Parrot_INTERP interp, Parrot_PMC pmc, Parrot_Int
value, Parrot_Int key)
to
void Parrot_PMC_set_intkey_intval(Parrot_INTERP interp, Parrot_PMC pmc, Parrot_Int
value, Parrot_Int key)
^slot type
^key type and variant
^action
which isn't the same order
This may be because the current order (action, slot type, variant/key type)
followed by value reflects the way my brain orders the importance of things.
Nicholas Clark
