On 5 January 2018 at 11:35, Dan Ackroyd <dan...@basereality.com> wrote: > On 5 January 2018 at 02:01, Michael Morris <tendo...@gmail.com> wrote: >> >> what if the underlying zval wasn’t a zval but a separate >> class specific to the data type but implementing the same interface as >> zval? > > I believe the only sensible answer to that is 'mu', as that question > is based on misunderstanding. > > The internals of the PHP engine is C, and zvals are structs not > classes, and so there is no interface. In userland classes are also > zvals. > http://www.phpinternalsbook.com/php7/internal_types/zvals/basic_structure.html
I think a good beginners intro is this, http://php.net/manual/de/internals2.variables.intro.php Yes, these things are structs, and there are no interfaces. It would be possible, in theory, to create a different struct for type-locked variables, where the type is not stored with each instance, but in the opcode. Or perhaps separate structs per type. This would obviously be a huge amount of work, and a radical change to the language, so I do not imagine this going to happen any time soon. Every place in code that currently deals with the _zval_struct would then have to consider all other structs. The opcode could then be optimized for such type-locked variables, and this would reduce cost in memory and performance. The next best thing would be to keep the existing _zval_struct also for type-locked variables, and still try to optimize the opcode as if the type is known at compile time. Still a lot of work, I imagine, because it still affects every place where we deal with a variable. The third option is to keep the implementation as if all types are dynamic, and only add some type checks here and there, which can be globally enabled or disabled. This is what other gradually typed languages do, as pointed out by Rowan Collins, > The biggest issue with any proposal, though, is going to be performance. I > don't think this is an incidental detail to be dealt with later, it is a > fundamental issue with the way type hints in PHP have evolved. PHP is > extremely unusual, if not unique, in exclusively enforcing type constraints > at runtime. Other languages with "gradual typing" such as Python, Hack, and > Dart, use the annotations only in separate static analysers and/or when a > runtime debug flag is set (similar to enabling assertions). > > Also, I think people who try to guess at how to make changes to the > engine, are doing a small disservice to people who have already tried > to implement this. This is a dilemma. I think there are some people with valuable opinions on language design, which did not find the time yet to study the engine implementation. So, either we risk occasional ignorant ideas, or we will miss some valuable contributions. I personally want to eventually study the engine in more detail, but I don't think I need to completely self-censor myself until then. Instead, I have to make a judgement call each time if my limited understanding is sufficient to allow a meaningful contribution to the discussion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
