On Wed, Jan 10, 2018 at 12:01 PM, Sara Golemon <poll...@php.net> wrote: > On Thu, Jan 4, 2018 at 8:21 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: >> I think you, and many others, commenting here, should start by looking >> at the engine implementation. Any successful RFC needs to have a strong >> implementation behind it, or at the very least a very detailed description of >> how the implementation would mesh with the existing engine code. >> >> The reason we don’t have typed properties/variables is that it would >> require adding type checks on almost every access to the underlying >> zval. That is a huge perf hit compared to only doing it on method/function >> egress points as we do now. >> > > **agh-mistabbed into a send
I'm going to underline Rasmus' comment here. zval assignment is a deep/core element of what the engine does. Even when it's not a literal `$x = "foo";` in userspace, zvals are flying around the engine constantly. Adding so much as a Z_TYPEINFO_P(val) & ZVAL_FLAG_STRICT check to EVERY ONE OF THOSE accesses is both heavy-weight and massively complex. On the order of the php-ng rewrite complexity, because EVERY assignment needs to be dealt with, and there WILL be some misbehaving extension out there which gets it wrong. The implementation essentials are not a trivial part of such a feature. You don't need to have the entire implementation written and tested, but you do need to have a clear plan for how and what will be done and vitally, what the impact of that plan will be. You can't just waive your hands and say: "We'll sort this out..." "How does HackLang do this?" has been asked of me offline, so I want to put my answer here: IT DOESN'T. HackLang relies of static analysis to prove "$x will never be assigned a non-integer, so we can always assume it's an integer". This is done by the static analysis tool before the site is ever run, not at runtime. Why? Because the HHVM could see the same thing Rasmus is telling you. Runtime type enforcement is damned expensive. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
