Re: Improved zend_string API

On Tue, Jun 30, 2015 at 8:15 AM, Bob Weinand <bobwei9@hotmail.com> wrote: >> Am 30.06.2015 um 12:53 schrieb François Laupretre <francois@php.net>: >> >>> De : Bob Weinand [mailto:bobwei9@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 ? > > I see where you're heading to. But I still hold my position that you're overvaluing > abstraction in that particular case. Like… it would be ideal to automatically reset the hash value > on each change. Do we want that? No. It'd do millions of useless hash-resetting operations. > So… what we end up? Having to manually control hash values. We always need to fallback to > low-level control, even though we have an API. That's not good. > It'd be nice to abstract it away, but that's at a cost we aren't willing to pay. > You only can have a certain level of abstraction without paying the price. > > I think, zend_string * may evolve without structure changes. But in case we change the > structures, something will have changed so drastically that the higher level APIs need change too. > I doubt that it will allow a lot. > > Let's take your example with "stricter" API. What can you now debug/monitor? > Like how a value changes? That you easily can right now with every smart C debugger… setting a > watchpoint. > Also, smart string is an own API, with dedicated functions. We can very well test that at that > level. No need to leak that over onto zend_string *. Smart string is a high-level API on top of > zend_string *, _using_ the primitive zend_string API. > > Oh, a check if it's in allocated bounds? Only issue is that we actually don't store > the boundaries (also no reason to) … anyway, I can guarantee that the prefect abstraction will be > leaky, or include a ton of functions operating on them. That's not the way to go. > Example… reallocing a string without setting a length (to extend but not knowing the exact > final length yet) … not possible, currently. I'm sure, if you search for cases where the > abstraction is leaky, you'll find enough. > Do NOT introduce leaky abstractions where it's not hiding complexity. > >>> 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. > > Okay. Other example. Refcounts. The macro itself still works… just that it'll badly fail > when you try to refcount a primitive type now. The changes leak on all levels … Oh sure. You could > have added a branch for each refcount checking the type… Just that will cost precious > instructions. > > Or IS_REFERENCE handling. A new type. Needs to be handled at all levels and beyond. > Or having now Z_STR() … sure, Z_STRVAL(), Z_STRLEN() still work, but became inefficient to > use. > > I could continue that list... > > Merci, > Bob > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Just to time in with my $0.02: I feel that using macros as an abstraction in this case is bad practice. I believe that in *most* cases macros as an abstraction is a bad practice. Furthermore, there isn't any reason that zend_string_* functions cannot act as an abstraction layer since zend_string's are passed by pointer.