> De : Bob Weinand [mailto:bobw...@hotmail.com] > > I see you changed the ZSTR_* macros to be pure aliases of the equivalent > structure members. > > May I now honestly ask where the benefit of those macros is? > > ZSTR_VAL(str) instead of str->val > ZSTR_H(str) instead of str->h > ZSTR_LEN(str) instead of str->len > > What is the point here? It's obvious why we have Z_* macros for the zval: > because of the unions. (Like nobody wants to write zv->value.lval instead of > just Z_LVAL_P(zv)) > It's a good thing to hide that union here. (Though I'd prefer anon unions, but > as I'm not sure what MSVC support here is, so no comment.) > > But there's no such reason for zend_string… > Hence the question remains, what value does it bring for zend_string? > Except that it obviously makes code harder to read? (It's longer, you can't be > sure about potential side effects etc.)
This is the last reply I send because, if you don't understand that the purpose of an API is not just to provide shortcuts for lazy developers, I cannot do much more for you. Read books, go to school, there must be a way... Well, I try again : *Today*, writing 'ZSTR_VAL(zstr)' or 'zstr->val' produces the same code. *Tomorrow*, when you will compile your code with a new version of 'zend_string.h', the generated code may change for different reasons. It's called 'loose vs tight' coupling and I stop here because there are tons of books explaining it much better than I do. Oh, and the 'obvious' reason why we have zval macros is not hiding the union level, it is to provide an abstraction layer. Once again, if we didn't have defined this layer a long time ago, PHP 7 would be very different or, even, couldn't exist. Please, read my previous message. I tried to explain the benefits of encapsulation but it seems the case is too hard for me. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
