+1 from me. It's worth noting that many of the problems you mention are problems with the VTABLE itself, not just the functions in src/extend_vtable.c. 3-argument arithmetic VTABLEs almost all follow that pattern (you must pass in the "destination", but it's typically ignored and a new one is created and returned). naming of vtables is inconsistent across the board too.
I suggest we maybe add in some kind of deprecation notice for "we're going to clean up the VTABLE structure and rename/fix/remove some things". There are a lot of fixes we can make in this area if consistency and efficiency are concerns. --Andrew Whitworth On Wed, Jan 12, 2011 at 11:23 AM, Jonathan Leto <[email protected]> wrote: > Howdy, > > I forgot to mention this at #ps, but I would like us to deprecate the > API that we expose in include/parrot/extend_vtable.h . > > Currently, the API is very inconsistently named: most in place > operations have an _i_ in their name, except for some, like > Parrot_PMC_increment and Parrot_PMC_decrement. > > Also, there is stuff like Parrot_PMC_get_integer vs Parrot_PMC_add_int. > > Also, the most broken thing seems to be stuff like this: > > pmc3 = Parrot_PMC_floor_divide(interp, pmc, pmc2, pmc3); > > That is, you must pass in pmc3 as an argument, but it is not used by > the function, since it returns the value. There are many functions in > the extend_vtable API with this pattern. > > A deprecation notice in 3.0 would allow us to tweak some of these > things or get rid of the entire API at some point, when the new embed > API is more featureful. > > If other Parrot devs agree with this sentiment, I will put in the > deprecation notice. > > Duke > > > -- > Jonathan "Duke" Leto > [email protected] > http://leto.net > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
