On Wed, 03 Dec 2003 11:52:35 +0100 Ulf Wendel <[EMAIL PROTECTED]> wrote:
obj->php_native_func() obj->myFunc()
Quick thought, does that work with overload? See Lukas post.
I'm not sure if I understand this. Is there any warranty that overloaded stuff will always follow the studyCaps rule? What about a function named "original_name()". Is there really a good reason why we must wrap it into OriginalName()? I'm afraid there's no one and only way.
Nevertheless I preferr PHP not to use studyCaps for it's native functions/methods/whatever. It seperates the build-in functionality nicely from my code.
PHP has strong roots in the C world. Most C programmers should expect that build-in labels (variables, constants, function names) use lowercase names including underscores. For those guys the absence of studyCaps is a clear indicator that they're dealing with build-in stuff.
Is it really true that the entire OO-world uses study caps? C++ is a hybrid language somewhatlike PHP. As far as I know STL does not use study caps.
Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody.
There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible).
What about the existing extensions that do use studycaps (GD)? Do not change them for backward compatibility. Allow them to keep their style for the functional an the OO API (if any). Finally try to replace the entire extension with a new one.
Ulf
-- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
