On Tue, Feb 17, 2015 at 5:05 PM, Nikita Popov <nikita....@gmail.com> wrote: > On Wed, Feb 18, 2015 at 1:53 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > >> On 02/17/2015 04:35 PM, Nikita Popov wrote: >> > I don't buy into Rasmus arguments about internal functions. They concern >> > one particular edge case (int->float coercion) and I doubt they have much >> > relevance if applied to codebases with pervasive use of typehints (where >> > you can be reasonably sure of the types of your variables). Even if, for >> > the sake of argument, we acknowledge the concern as valid we should be >> > discussing that particular case (int->float coercion) rather than >> dropping >> > the strict typing for internal functions altogether. >> >> int->float is actually secondary to "123"->int. And while they may be >> edge-cases there are enough of them that we would be pushing people >> towards casting by default which should be a last-resort thing, not the >> first thing you do. >> > > The inability to implicitly cast "123" to int is pretty much the KEY > distinction between weak and strict scalar typehints (those pesky > value-dependent type checks). If the strict typing mode doesn't offer this, > what's the point at all? > > This is exactly what I fear will happen with an arginfo based approach. If > even fundamental aspects like the "123" vs 123 (or true vs 1) distinction > are suppressed for internal functions, this isn't a strict typing mode, > it's just a weak typing mode with slightly different rules.
I totally agree with you here, and with your next more verbose reply. I am astonished to see where this discussion simply redo what we discussed to death already and basically see no progress toward a compromise but a way to get weak typing in place. I do not see much value to argue in circle forever and will actually support what I consider as good once there is a RFC in place. Weak typing only won't be the one I would choose. I remain a fervent supporter of the previously proposed dual mode, which actually covers all we need. Yes, there are implementation details (I repeat: yes, I do consider most of the raised issues as implementation details), but generally it is the compromises and way I see as the way to go. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
