> De : Bob Weinand [mailto:bobw...@hotmail.com] > > Precisely. Instead of tight coupling to the structure, we now couple to the > macro… and it's not like the macro will be left untouched once we change the > underlying structure.
There are different levels of encapsulation : 1st level can be seen as the C structure, 2nd level is the macro (allows to change the structure organization), 3rd level provides separate read-only getters and write-only setters. If you look at https://github.com/php/php-src/pull/1381, you will see the API I want to integrate (not sure there is enough time before 7.0 freeze). It doesn't use macros any more but active methods/functions. There, ZSTR_LEN() is a pure getter, which cannot be used as lvalue. ZSTR_SET_LEN() is the corresponding write-only setter. I don't say that such API is supposed to resist any implementation change but it should already allow a lot. When we achieve this encapsulation level on arrays/HashTables, we'll be much more comfortable with future potential changes. I understand your pov. If any future change in the underlying implementation requires changing the API, this API is much less valuable. You think that zend_string internal implementation will never evolve without requiring API changes. I don't think the same, I make no assumption on other's creativity, I just know that, if the need for a better isolation arises someday, it will be too late. So, I prefer to have it from the beginning. In zend_string, the need comes more from the countless number of locations accessing the API than from the implementation complexity. Of course, when we have both, like on arrays, isolation is still more important. Once again, zend_string is just an example. Zval needs some work too but is somewhat easier as an extensive API already exists and most people use it, it just needs to be made 'stricter'. Making the zval API stricter (with separate getters/setters) will allow for a lot of debugging/monitoring instrumentation to be added to the API. Some of them are also interesting for zend_strings. Just imagine simple checks in debug mode ensuring the string length remains in allocated bounds. If you set the length using a '->len' assignment or a macro, it cannot be trapped and checked. It is really the simplest example of what encapsulation makes possible. When we work on zend_string/smart_str integration, code can also be inserted to measure the efficiency of various over-allocation policies. With you '->len', what will you do ? "grep '--' '->len' `find . -type f`" and rewrite thousands of occurrences ? > Like … PHP 7 changed the semantics of Z_TYPE() macro… you can no longer > assign directly to it. We anyway have to change our code. > It's rare that such underlying changes don't leak through the API. No, we need to change our code because the zval API's encapsulation level was not high enough. It type setters and getters had been already separate in PHP 5, switching to PHP 7 wouldn't have required changing our code. That's why defining access macros is not enough. We need stricter 'methods', designed as services. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
