> Those who pay attention to my occasional ramblings may remember that I > once suggested implementing "type hints", which is a more generic > version of this. Type hints is like your string types, except that they > apply to any type.
I haven't been subscribed, so I don't remember. :-) I am certainly open to a generalization of this, but I can't really imagine what it means for other types than string - I'll try looking up your messages in the archive. For strings, I propose making an extensible (at runtime) registry of string types (with a few built-in, at least those that I already made); for each string type, the programmer would supply a function that would convert it to a string type given as a parameter. The additional performace hit (to my original proposal) shouldn't be too great, since it would only occur when converting strings, which is a process that the programmer would have to do anyway, just differently. > I guess the core issue here is whether adding an int to zval or > zval.value.str is worth the cost. With all the zval copying going on, > there will be a cpu overhead as well as memory. Well, I assumed that the overhead wouldn't be too significant, but I admit I didn't do any measurements whatsoever. Is there any existing good benchmark, or should I just loop a million times through a few random lines of code and measure this? > Back when Andi moved zval.value.strlen and zval.value.strval into > the str struct, thus saving 4 bytes in the zval struct, PHP 3 was > generally speeded up by 25%. WHAT??? Well, since this would add them back again... :-( > Not sure if the PHP 4 or PHP 5 overhead will be in the same > ballpark, but it's something to think about. Definitely. Although I love my idea, I guess I'd give it up myself if it proves to be such a slow-down. Of course, it could be made a compile-time configuration option, but I don't think that's very useful. The programmer couldn't be sure beforehand what version of the language his web-hoster will be using... :-( (Which is a part of what I wanted to avoid by this - eliminate comfortably one dependence on configuration: the magic_quotes_gpc option.) > IMHO the syntax you suggest is a bit terse, what about this instead: > > echo url"http://$host:$port/$path";; Personally, I don't really care, and it's easy to change, so why not? It would certainly need to allow for longer type names if it were to be general, which I now want to implement. > As for the SQL string type, there needs to be at least two, some > databases quote "'" as "''", others quote it as "\'". This is set by cfg. option magic_quotes_sybase, so I don't think it's necessary (the web-hoster should set it depending on which database they provide; the programmer shouldn't even need to care about it). But there could be one sql-type which follows the m_q_s setting, and two others for each possibility. > But I would like to extend the idea beyond reformatting inserted > strings. For example, for easy soap/xmlrpc serialization, being able to > tag a value as a date or some other soap/xmlrpc-specific type is very > useful. I know nothing about soap/xmlrpc, but... How about making a reserved method name for objects that would - if it exists - be called when that object should be converted to a string? class Date { function __to_string($type) { # return a string with $this formatted as $type string } } $date = new Date(); echo xml"<date>$date</date>"; Hmmmm...?? BTW, Python now has the possibility of inheriting classes from built- in types, which would sure come in handy here... BTW2, as I describe on the webpage that I announced, I wasn't able to successfully run the self-test suite (make test). Could someone please tell me what I am doing wrong (see the description at the url)? Thanks. The URL is, again: http://nebuchadnezzar.zion.cz/php_strings.php Vaclav Dvorak ([EMAIL PROTECTED]) http://nebuchadnezzar.zion.cz/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
