DEPRECATE (after review) the *bigint*, pow* and nextkey_keyed VTABLE functions

[bacek]

Current nomenclature of VTABLEs is bloated and requires cleanup. The following functions can be removed at any time post-1.0:

get_bigint
set_bigint_*
pow
i_pow
nextkey_keyed*

-- Bacek

[allison]

nextkey_keyed* I can see, if they're no longer needed for iterators (they never were a good way to implement iterators anyway). I don't see the reasoning for bigint and pow, could you explain your thoughts?

[bacek]

Just as cleanup of rare used code.

1. get_bignum is just shortcut for $P0 = new 'BigNum'; set $P0, orig. And only one "real" usage is inside Integer PMC.

2. set_bignum_* isn't used anywhere in Parrot. And not exposed in ops.

3. pow/i_pow for consistency sake. Why we have VTABLE_pow, but not "exp", "ln", etc?

-- Bacek

[allison]

1. Except that it's impossible to retrieve a bignum value from another PMC without get_bignum, because an N register can't hold the value.

3. The same could be argued for all the math vtable functions, but you have to draw the line somewhere. Simple "to the power of X" is a common operation, exp and ln aren't.

nextkey_keyed* can go, but the bignum and pow vtable functions stay.

[bacek]

Replying to allison:

1. Except that it's impossible to retrieve a bignum value from another PMC without get_bignum, because an N register can't hold the value.

Ok. Let's add "get_complex". For exactly same reason...

Agree (but dislike it) with math ops.

There is more vtables to review:

• set_bignum_int (which is not used at all.)

• get_repr (which have notice in pdd17 about redundancy with get_string)

• assing_string_native/set_string_native looks pretty duplicates.

• "string" versions of bitwise operators. Do we really need them? How often they are used. Can we hust replace them with METHODs?

*ADD* more VTABLEs for consistency sake:

• i_logical_or, _and, _xor

-- Bacek

[bacek]

set_*_same VTABLE functions were removed in r41229.