OK. So common decision not ot apply this. May be sombody will get some other ideas?
Thanks. Dmitry. > -----Original Message----- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 07, 2006 10:39 PM > To: Dmitry Stogov > Cc: php-i18n@lists.php.net; Andrei Zmievski; Andi Gutmans > Subject: Re: [PHP-I18N] Ideas for a portable string api > > > Hello Dmitry, > > i looked at the patch and must say that you did it better > than i thought of when i first came to the idea but well you > already told us that you can do it much better. However i > must also admit that it doesn't buy us much. So i guess we > can also stay with what we have and move along as Andrei > prefers. In the end the question is whether we want to make > our developers learn more macros or more parameter orders. > > best regards > marcus > > Tuesday, March 7, 2006, 1:06:53 PM, you wrote: > > > Hi, > > > The patch in attachment implements S_ARG(...) and related macroses. > > However I don't like to commit it. Because code isn't more > clear with > > these macroses and it is harder to debug. I prefer stay API as is. > > > Thanks. Dmitry. > > > >> -----Original Message----- > >> From: Dmitry Stogov [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, February 16, 2006 12:12 PM > >> To: php-i18n@lists.php.net > >> Subject: RE: [PHP-I18N] Ideas for a portable string api > >> > >> > >> Hi, > >> > >> After reviewing Marcus ideas, some experiments and speaking > >> with Andrei. I propose the following solutions: > >> > >> 1) We will not use any kind of unicode literals in C code (no > >> L"foo" no "f\0o\0o\0\0"), Because L"" is not portable and > >> "f\0.." looks to ugly. > >> > >> 2) We will change "zval" structure to make > >> "zval.value.str.len" and "zval.value.ustr.len" of the same > >> type. This will allow optimize Z_UNISTR() and Z_UNILEN() > >> macros. They will > >> > >> #define Z_UNISTR(z) ((void*)(Z_STRVAL(z))) > >> #define Z_UNILEN(z) ((void*)(Z_STRLEN(z))) > >> > >> Instead of > >> > >> #define Z_UNISTR(z) > >> Z_TYPE(z)==IS_UNICODE?(char*)Z_USTRVAL(z):Z_STRVAL(z) > >> #define Z_UNILEN(z) > >> Z_TYPE(z)==IS_UNICODE?(int)Z_USTRLEN(z):Z_STRLEN(z) > >> > >> 3) I don't like to break source compatibility with > >> modification of "zval" layout as Marcus suggested. We will > >> pass string/unicode values near in the same way as do today. > >> As three values - zend_uchar type, void* str, int len. But we > >> will create a set of the following macros to do it with > less overhead. > >> > >> #define S_TYPE(x) _type_##x > >> #define S_UNIVAL(x) _val_##x > >> #define S_UNILEN(x) _len_##x > >> #define S_STRVAL(x) ((char*)S_UNIVAL(x)) > >> #define S_USTRVAL(x) ((UChar*)S_UNIVAL(x)) > >> #define S_STRLEN(x) S_UNILEN(x) > >> #define S_USTRLEN(x) S_UNILEN(x) > >> > >> #define S_ARG(x) zend_uchar S_TYPE(x), void > >> *S_UNIVAL(x), int > >> S_UNILEN(x) > >> > >> #define S_PASS(x) S_TYPE(x), S_UNIVAL(x), S_UNILEN(x) > >> > >> #define Z_STR_PASS(x) Z_TYPE(x), Z_UNIVAL(x), Z_UNILEN(x) > >> #define Z_STR_PASS_P(x) Z_TYPE_P(x), Z_UNIVAL_P(x), > >> Z_UNILEN_P(x) > >> #define Z_STR_PASS_PP(x) Z_TYPE_PP(x), Z_UNIVAL_PP(x), > >> Z_UNILEN_PP(x) > >> > >> Then most zend_u_... Functions must be rewriten with these macros > >> > >> Foe example: > >> > >> ZEND_API int zend_u_lookup_class(S_ARG(name), > zend_class_entry ***ce > >> TSRMLS_DC) > >> { > >> return zend_u_lookup_class_ex(S_PASS(name), 1, ce > TSRMLS_CC); } > >> > >> Instead of > >> > >> ZEND_API int zend_u_lookup_class(zend_uchar type, void *name, > >> int name_length, zend_class_entry ***ce TSRMLS_DC) { > >> return zend_u_lookup_class_ex(type, name, name_length, > >> 1, ce TSRMLS_CC); } > >> > >> Any objections, additions? > >> > >> Thanks. Dmitry. > >> > >> -- > >> PHP Unicode & I18N Mailing List (http://www.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > >> > > > > -- > Best regards, > marcus > > > -- PHP Unicode & I18N Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
