> Am 30.06.2015 um 05:44 schrieb François Laupretre <franc...@php.net>: > >> 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...
APIs are there to abstract complexity away. Is there complexity? No. … And *additionally* it doesn't even add readability. > 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. 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. Did you see what changed with the arrays? We changed our underlying structures a lot… but had to adjust our APIs to make them fit to the underlying structures. > 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. Oh, please, tell me why it would have been an issue? We'd just have changed our direct type value access to a Z_TYPE() access with PHP 7 (as there is now complexity which is a good thing to hide with PHP 7). 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. > Please, read my previous message. I tried to explain the benefits of > encapsulation but it seems the case is too hard for me. Yes, I did; but I hadn't received your message yet before I sent that mail ;-) I generally have the feeling that you strongly overvalue encapsulation. Encapsulation makes things easier, some implementation details are changeable then, but e.g. zend_string * is already very low-level. Nearly every change on zend_string * will leak through the API encapsulating it. It's not the holy grail of forward compatibility. Use it where appropriate; don't _abuse_ it. > Regards > > François Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
