If we can avoid a painful transition for users, I'd like to see this too. The ideal should be to have a completely unsurprising set of VTABLE functions. We should have a general format and set of conventions such that if you know the name of a function, it's easy to guess how it's used (arguments and return values) and which prefixes and suffixes it has. It doesn't matter much to me what the convention is, as long as it's predictable.
Christoph > -----Original Message----- > From: [email protected] [mailto:parrot-dev- > [email protected]] On Behalf Of Andrew Whitworth > Sent: Wednesday, January 12, 2011 08:29 > To: Jonathan Leto > Cc: parrot-dev > Subject: Re: Deprecate current extend_vtable API for 3.0 > > +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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
