> On 14 Oct 2014, at 09:51, Stas Malyshev <smalys...@sugarcrm.com> wrote: > > Hi! > > >> Since I don’t want this to languish as a ‘Draft’ forever, despite the >> patch being incomplete, I am finally putting the Big Integer Support >> RFC “Under Discussion”. >> >> The RFC can be found here: https://wiki.php.net/rfc/bigint > > This introduces new type, IS_BIGINT. However, given that GMP now > supports arithmetical operations, I wonder if it won't be easier to do > it in slightly different way, specifically create a hook that is going > to be called when an operation is about to cause over/underflow and let > GMP hook there and produce a GMP number (I'm not sure about the exact > details how to actually do it, so it's just an idea now, but if it makes > sense we can try to work out technical details). > > Of course, this would require some rough edges to be polished, such as > what happens if you try to use it as int, or convert, etc. but this is > already present with IS_BIGINT too, and additionally we already have > conversion handlers for objects, which aren't consistently used in all > cases but can be made so. The benefit is we're not creating anything > completely new, we just improving how objects work. > > This would also allow anybody who doesn't like GMP big integers easily > implement their own module to replace them. > > Moreover, this also allows to make the support for bigints optional - > i.e., if you don't need bigints, you don't have to carry GMP and thus do > not have to be bound by its license. > > What do you think?
I'm not sure what this would solve. Sure, you could just use objects instead of a new type, but both present exactly the same challenges. Adding a new type isn't hard in itself. The problem is updating everything which handles numbers and their associated tests. This doesn't make my job any easier. It also wouldn't cover a few places that a new type can, like constants. Another problem is this means that bigints are a separate thing from ints, meaning users have to worry about a new type which sometimes behaves differently. This isn't good. Under this RFC's proposal, however, bigints are a mere implementation detail. So far as the user cares, there are just ints. Making it optional destroys most of the benefits of the RFC. Instead of reducing platform differences, it adds a massive new one. Now developers have to check whether or not bigints are enabled and have two different code paths. That's much worse than the status quo. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
