Hi! > We already have this danger for another type: boolean. phpng got rid > of IS_BOOL in favour of IS_TRUE and IS_FALSE. If we can update > everything to handle the IS_BOOL change, surely we can update > everything to handle bigints, too.
No, it's not the same thing at all. For bool, you still have only true and false. For bigint, your function now should be able to handle infinite integers internally, but what if it has fixed resources that assume integers have fixed range? For extensions, it's a commonplace, but even for user code that can happen. That means, any call that you do to an internal function with int argument now could fail since the internal function is unable to support bigint, and you can't even guard for this since your code can not distinguish regular int from bigint. I don't think it is a good situation. > Then get weird results when someone passes a large number in. Why would you get weird results? You describe some vague dangers but I didn't see any concrete example of what is different. > The main point of the RFC is to make integers completely consistent > across platforms and to remove the need to worry about overflow. Which does not change with my proposal. > Adding optional overflow to GMP means you still have to worry about > it. It doesn’t solve anything. You can already use GMP for You seem to misunderstand what my proposal is. It doesn't add any additional overflow, it just changes from using separate type masquerading as int to using objects. All the rest stays the same. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
