On 02/02/15 20:15, Robert Stoll wrote: > Nobody would stop you from implementing a utility class Money or likewise and > providing a better error message instead of using int if PHP would be strict > only (what is not proposed in the RFC anyway). You could also just omit the > type hint, it is entirely up to you. The point here was that this is creating yet another set of rules that only apply in some cases. Rather than perhaps looking at a more generic solution that can be used in validation across all types.
> There are plenty of strongly typed languages out there which work very well > without the mentioned lack of specific error messages for each individual use > case. Lived with that in the past ... having to convert everything TO some common type before using it is just as irritating. PHP's lighter touch especially where data is coming in mainly from a string based feed is much nicer to work with. > And btw. PHP is strict for array and class type hints as well - of course > you can also omit those type hints. Which are creating even more conflicts. The ONE element that I am growing concerned about is a simple 64bit BIGINT primary key which can be used as an array index. A strict integer is heading towards some complex variable length data type, while for probably 99.9% of database related BIGINT data it is a simple integer. If third party libraries move towards a 'strict' style of working they may not be efficient when used without that practice, or they may not play nicely with other interfaces that have a different 'strict' view. There are a growing number of low cost devices which are essentially 32 bit devices, but with 64 bit maths which is possibly incompatible with the current 'strict' view of data within PHP. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
