I have not had an answer yet so I will rephrase the question.
Not following all the discussions on studlyCaps and their
adoption, I am having a little trouble understanding the
implications.
The current php manual has hundreds of functions with
underscore in the name. Are these all going to be replaced?
In which case ALL existing script has to be re-written?
If not, just where is the line drawn?
I hope that people can see my confusion.
--
Lester Caine
L.S.Caine Electronic Services
Lester Caine wrote:
The current php manual has hundreds of functions with underscore in the
name. Are these all going to be replaced? In which case ALL existing
script has to be re-written?
No, studly caps have been adopted as a standard only for method names in
the OO-style API, not for the procedural API.
--
Ard
Ard Biesheuvel wrote:
Lester Caine wrote:
The current php manual has hundreds of functions with underscore in
the name. Are these all going to be replaced? In which case ALL
existing script has to be re-written?No, studly caps have been adopted as a standard only for method names in
the OO-style API, not for the procedural API.
Thanks for that.
So it IS something that I will have to take account of when
I start looking at moving the interbase module to a firebird
native version. If the interbase module accesses the
OO-style API. If it does not, then I presume that it may be
advantageous to handle any required conversions then?
--
Lester Caine
L.S.Caine Electronic Services
Lester Caine wrote:
So it IS something that I will have to take account of when I start
looking at moving the interbase module to a firebird native version. If
the interbase module accesses the OO-style API. If it does not, then I
presume that it may be advantageous to handle any required conversions
then?
Interesting ...
I am curious what your motivation is for moving the Interbase module to
a fb version. Furthermore, the studly caps standard was adopted for PHP
methods, and not for the C (implementation) level, so this will hardly
be of influence to extension implementers.
--
Ard
Ard Biesheuvel wrote:
Interesting ...
I am curious what your motivation is for moving the Interbase module to
a fb version.
Divergence of the API layers, and I would like to get into
some of the facilities that are currently not very well
supported. There is no panic on this which is why I'm happy
to wait until PHP5 has been released, but it may become a
problem.
Furthermore, the studly caps standard was adopted for PHP
methods, and not for the C (implementation) level, so this will hardly
be of influence to extension implementers.
I've spent a lot more time fault finding with the likes of
the ADOdb layer, than the next layer down, and currently
having to live with the inactivity of Borland on Builder VCL
support, I'm looking to the future. When I see major changes
taking place I get a bit jittery - I've already lived
through three rebuilds of my application code base thanks to
Borland, and so I don't want to back the wrong horse this
time :)
--
Lester Caine
L.S.Caine Electronic Services