Re: [PHP4BETA] cvs: /php4 php.h /php4/ext/standard basic_functions.c basic_functions.h php3_string.h string.c /php4/tests testarray

At 02:04 21/09/1999 , Rasmus Lerdorf wrote:

1. They are in fact querying Zend's internals and are a language-level feature (unlike strlen() or any of the other functions Andi moved). How are they more language-level features than something like each?

They touch the argument stack not through Zend's API (i.e., you're not allowed to do that unless you're a part of the scripting engine yourself).

2. I didn't want to use non-prefixed names in order not to clash with people's functions. We have added a number of new functions and none of them have gotten weird prefixes. I really don't agree that any basic language-level functions should be prefixed with zend_ or php_ or anything like that. Either the function is important enough to be added and risk the incompatibility or it isn't. Prefixed functions are messy and will only serve to confuse people when it comes to the PHP/Zend combination.

I don't agree at all that prefixed functions are messy. Provided you dig up the right prefix, prefixed functions make up for the lack of namespaces (consider all of our modules as a good example). There are quite a few functions today (e.g. count(), current(), next()) that would have been much better off prefixed (e.g. array_count(), array_current(), array_next()), and I don't want to make the same mistake with new functions. I thought about this while driving home (it may or may not surprise you, but I wasn't happy with the zend_ prefix either), and I think that going for an informative prefix is the way to go. In this case, I'd go with uf_*(), standing for User Function. That would give us uf_num_args() and uf_get_arg(). Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il