Re: [PHP-I18N] Ideas for a portable string api

I actually agree.. The more macros we add, the more confusing it 
becomes. I had to look back and forth a few times between S_PASS() and 
Z_PASS() to figure it out. I guess Marcus was the one who wanted 
simpler API, so what does he think?

-Andrei

On Mar 7, 2006, at 4:06 AM, Dmitry Stogov 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: [email protected]
>> 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
>>
>>
>>
> <s_arg.diff.gz>