Hello,

On Wed, 03 Dec 2003 14:02:00 +0100
Ulf Wendel <[EMAIL PROTECTED]> wrote:

> 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.

I like the counter and nicely move from PHP classes to the module
versions depending on which configuration I work, or when I 
overload/extend an "internal" object.

> 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.

See Morioshy post (python as well), most of the langages with OO
features use studlycaps. STL..., well  ;-)

> 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.

A OO API can add many advantages or conveniences ways that are
impossible to do with with a functionnal approach. New ways, new
features, new names, nothing to make Jon Doo confused :)

> 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).

Or drop the incosistencies instead of keeping them.

> What about the existing extensions that do use studycaps (GD)? Do not 
> change them for backward compatibility. Allow them to keep their style

This BC thingies in PHP5 sound always weird or silly to me (in most
cases). Why in the world do we need a major release if on each case we
have to take care of php4?

> for the functional an the OO API (if any). Finally try to replace the 
> entire extension with a new one.

Which should be the case anyway, to use  the new engine features, if
required.

pierre

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to