#866: DEPRECATE (after review) the *bigint*, pow* and nextkey_keyed VTABLE
functions
--------------------+-------------------------------------------------------
Reporter: bacek | Owner:
Type: RFC | Status: new
Priority: normal | Milestone:
Component: core | Version: 1.3.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
--------------------+-------------------------------------------------------
Comment(by whiteknight):
I got sidetracked and didn't talk about how lousy the pow_* vtables are
either. By my count we have 6 such vtables: pow, pow_int, pow_float,
i_pow, i_pow_int, and i_pow_float. Considering how infrequently used any
pow() operations, it seems absurd that every single VTABLE structure for
every single PMC needs to have 6 pointers reserved to it.
We have a small handful of types that implement any of the pow variants:
Complex, Integer, BigNum, Scalar, BigInt, and default. default redirects
all requests to MMD, Integer and Scalar define all variants following a
template similar to the following:
{{{
VTABLE void i_pow_float(FLOATVAL value) {
VTABLE_set_number_native(INTERP, SELF,
pow(SELF.get_number(), value));
}
}}}
If all we need is a thin wrapper around libc's pow() function, we could
easily provide that in an op or even a runtime loadable library function.
There's no reason to have 6 VTABLEs that are not defined in most types and
where they are defined they mostly fall back to libc's pow() function.
This also raises an incongruity where we are missing such treatment of
other oft-unused libc functions like log(), log10(), ln(), sin(), cos(),
etc. The same reason why we don't want to add 6 VTABLEs for each of these
operations is the exact same reason why we shouldn't have them for pow().
That said, there are some types that do make legitimate use of pow:
Complex, BigNum, and BigInt. However I would suggest that all these types
should encapsulate the necessary behavior in methods and not require all
PMC types to allocate storage for pointers to pow functions when most PMCs
won't use them.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/866#comment:11>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
