Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

[Boian Bonev]

hi,

> I am for uniform names but not if it's at the price of adding a zillion of
> aliases or at a price of making 50% of people's old scripts not work. I am
> also very much against compile-time options because I'd expect a script
> written in PHP and posted on some sites code exchange to work for
everybody.

code exchange do not work well even now - think about magic quotes and magic
quotes runtime.

compile-time defaut of some old versions of php (3.x as far as i remember)
is to disable magic quotes. my setup is
magic quotes set to yes, runtime to no.

many hosting providers still have a default setup of php3 and making a
shareable script needs the get_magic_quotes_qpc/set_magic_quotes_runtime and
addslashesh stuff. why make more difficulties? if there is an option about
function aliases then there will be times more different (incompatible)
envirnonments than now and perhapse autoconf stuff will be needed to setup
and run a simple php script on different server... just imagine the
"Checking for is_alpha..." ;-)

b.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV]ctype function (re?)naming

[Zak Greant]

I post my suggestions later today. :)

--zak

- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Zak Greant" <[EMAIL PROTECTED]>; "Phil Driscoll"
<[EMAIL PROTECTED]>; "Stanislav Malyshev" <[EMAIL PROTECTED]>; "PHP
Development" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, March 02, 2001 2:55 AM
Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re:
[PHP-DEV]ctype function (re?)naming


> We should probably just make a list of all the effected functions and see
> which ones we start fixing and which not.
> And of course it has to be a very gradual death of the old functions
> similar to the way described on the QA list a while ago about having a
> warning after a few versions and only then nuking the aliases.
> By the way, we already have some ugly aliases today which I'd love to nuke
:)
>
> But guys, there's one thing you need to remember and I've seen it in the
> past. The amount of people you think will get bitten by something this
> small is usually 10 times more than you really think :'(
>
> Andi
>
> At 09:24 PM 3/1/2001 -0700, Ron Chmara wrote:
> >Andi Gutmans wrote:
> > > It doesn't make much sense to go back and break old names and it
doesn't
> > > make lots of sense to create a zillion of aliases. I guess if there
are
> > some
> > > names which in particular need fixing because they are terrible (there
> > > might be some of these) then we should fix them on a per-function
basis.
> >
> >"zillion" is a bit hard to pin down, isn't it? :-)
> >
> >I took a swipe at figuring out the scope of the issue, and we have a
> >small mix of variants in a mostly consistent set of names. I'd say less
> >than a zillion. A bunch or so, maybe? ;-)
> >
> >If done as a "think about this when updating and editing old code"
problem,
> >the task of aliasing becomes much smaller, and much more achievable. It
> >also becomes less wasteful, as functions which aren't being actively
> >used (and thus, maintained) can atrophy gracefully, without having all
> >sorts of aliases created for a mostly unused function. (Example: Oracle
> >functions are slowly falling away, being replaced by OCI, swf functions
> >are doing a similar thing.)
> >
> > > I am for uniform names but not if it's at the price of adding a
zillion of
> > > aliases or at a price of making 50% of people's old scripts not work.
I am
> > > also very much against compile-time options because I'd expect a
script
> > > written in PHP and posted on some sites code exchange to work for
> > everybody.
> >
> >I'd definitely agree with both points, but am wondering if there's a
> >"reasonable"
> >limit on supporting old scripts. (I'd call reasonable 6 years worth of
> >code, or three major codebase rewrites).
> >
> >(Thanks for the humor Zak, it helps... I'm gonna go cry, hold onto
> >my woogie, and see if I can remember heim_unblock())
> >:-)
> >
> >-Bop
> >
> >--2D426F70|759328624|00101101011001100111
> >Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
> >Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
> >The opinions expressed in this email are not necessarily those of myself,
> >my employers, or any of the other little voices in my head.
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV]ctype function (re?)naming

[Andi Gutmans]

We should probably just make a list of all the effected functions and see 
which ones we start fixing and which not.
And of course it has to be a very gradual death of the old functions 
similar to the way described on the QA list a while ago about having a 
warning after a few versions and only then nuking the aliases.
By the way, we already have some ugly aliases today which I'd love to nuke :)

But guys, there's one thing you need to remember and I've seen it in the 
past. The amount of people you think will get bitten by something this 
small is usually 10 times more than you really think :'(

Andi

At 09:24 PM 3/1/2001 -0700, Ron Chmara wrote:
>Andi Gutmans wrote:
> > It doesn't make much sense to go back and break old names and it doesn't
> > make lots of sense to create a zillion of aliases. I guess if there are 
> some
> > names which in particular need fixing because they are terrible (there
> > might be some of these) then we should fix them on a per-function basis.
>
>"zillion" is a bit hard to pin down, isn't it? :-)
>
>I took a swipe at figuring out the scope of the issue, and we have a
>small mix of variants in a mostly consistent set of names. I'd say less
>than a zillion. A bunch or so, maybe? ;-)
>
>If done as a "think about this when updating and editing old code" problem,
>the task of aliasing becomes much smaller, and much more achievable. It
>also becomes less wasteful, as functions which aren't being actively
>used (and thus, maintained) can atrophy gracefully, without having all
>sorts of aliases created for a mostly unused function. (Example: Oracle
>functions are slowly falling away, being replaced by OCI, swf functions
>are doing a similar thing.)
>
> > I am for uniform names but not if it's at the price of adding a zillion of
> > aliases or at a price of making 50% of people's old scripts not work. I am
> > also very much against compile-time options because I'd expect a script
> > written in PHP and posted on some sites code exchange to work for 
> everybody.
>
>I'd definitely agree with both points, but am wondering if there's a 
>"reasonable"
>limit on supporting old scripts. (I'd call reasonable 6 years worth of
>code, or three major codebase rewrites).
>
>(Thanks for the humor Zak, it helps... I'm gonna go cry, hold onto
>my woogie, and see if I can remember heim_unblock())
>:-)
>
>-Bop
>
>--2D426F70|759328624|00101101011001100111
>Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
>Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
>The opinions expressed in this email are not necessarily those of myself,
>my employers, or any of the other little voices in my head.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re:[PHP-DEV]ctype function (re?)naming

[Ron Chmara]

Andi Gutmans wrote:
> It doesn't make much sense to go back and break old names and it doesn't
> make lots of sense to create a zillion of aliases. I guess if there are some
> names which in particular need fixing because they are terrible (there
> might be some of these) then we should fix them on a per-function basis.

"zillion" is a bit hard to pin down, isn't it? :-)

I took a swipe at figuring out the scope of the issue, and we have a
small mix of variants in a mostly consistent set of names. I'd say less
than a zillion. A bunch or so, maybe? ;-)

If done as a "think about this when updating and editing old code" problem,
the task of aliasing becomes much smaller, and much more achievable. It
also becomes less wasteful, as functions which aren't being actively
used (and thus, maintained) can atrophy gracefully, without having all
sorts of aliases created for a mostly unused function. (Example: Oracle
functions are slowly falling away, being replaced by OCI, swf functions
are doing a similar thing.)

> I am for uniform names but not if it's at the price of adding a zillion of
> aliases or at a price of making 50% of people's old scripts not work. I am
> also very much against compile-time options because I'd expect a script
> written in PHP and posted on some sites code exchange to work for everybody.

I'd definitely agree with both points, but am wondering if there's a "reasonable"
limit on supporting old scripts. (I'd call reasonable 6 years worth of
code, or three major codebase rewrites).

(Thanks for the humor Zak, it helps... I'm gonna go cry, hold onto
my woogie, and see if I can remember heim_unblock())
:-)

-Bop

--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

[Andi Gutmans]

We're probably best off staying with the status quo and trying to keep a 
close look at any new modules which make it into the tree and modules which 
have been added since 4.0.4 (or maybe a small time before).
It doesn't make much sense to go back and break old names and it doesn't 
make lots of sense to create a zillion of aliases.I guess if there are some 
names which in particular need fixing because they are terrible (there 
might be some of these) then we should fix them on a per-function basis.
I am for uniform names but not if it's at the price of adding a zillion of 
aliases or at a price of making 50% of people's old scripts not work. I am 
also very much against compile-time options because I'd expect a script 
written in PHP and posted on some sites code exchange to work for everybody.

Andi

At 04:04 AM 3/1/2001 -0700, Zak Greant wrote:
>Phil wrote:
> > Ron - whose postings I normally agree with :-) - wrote:
>
>As do I :)
>
>[snip]
>
> > I know that Zak has been doing some experiments along these lines, but has
> > also been busy on other projects. Any news to report Zak?
>
>I now have less hair that I did before starting. ;)  Finding sensible
>consistent names for the function is somewhat of an undertaking.  I am still
>working on it
>
>I have been twiddling away with a few ideas and have come to some
>conclusions.
>
>Naming is broken.
>
>Points in case: defined, function_exists, isset and class_exists...
>
>We should have a set of standard verbs that we use for cases like this.  I
>would like to see something like:
>
>function_defined
>class_defined
>var[iable]_defined
>constant_defined
>
>We can't agree
>==
>No consensus on this issue can be reached.
>
>We seem to have several schools of thought on this issue.  Here are my
>bitter, narrow, soft-headed and sarcastic views on them:
>
>Deny the existence of a problem :)
>
>There is no problem with the function names. So stop yer whining or we'll
>make you use Damian Conway's Lingua::Romana::Perligata instead of PHP.
>Well, ok... there may be a problem, but I am not convinced of it.  And if
>there were a problem, we need a better way to fix it than has been yet
>proposed.
>
>Live in eternal fear of backwards compatibility :)
>--
>When issues of function renaming arise, frighten all the little hackers with
>stories of how the villagers will rise against us if we break backwards
>compatibility with PHP 2.
>
>Refuse to relinquish old C function names :)
>-
>At the first sign of any change to the function names, cling tightly to your
>'woogie' and begin to cry. They can't make you give up your woogie - why,
>you;'d rather shave off your beard and give up your suspenders than live
>life without your woogie.
>
>Bite off more than you can chew :)
>-
>Attempt to swallow large issues in a single bite and end up choking on your
>wishful thinking.  Core developers stand around you and make bets on what
>color your face will turn before someone remembers the function name for the
>Heimlich manuever (is that apply_heimlich_manuever, heim, heimApp,
>windpipe_clear... or was it set_socket_blocking (FALSE)
>
>Expand the scope of the argument :)
>--
>Expand the argument scope until it encompasses almost every aspect of the
>language. Wonder why everone else looks at you like you are a large
>cockroach.
>
>Hamstring the discussion :)
>-
>Ignore the thread til it looks like it is getting somewhere, then unload one
>crippling message and retreat from the ensuing carnage.
>
>
>Seriously, this is a bugger to resolve!  I don't think that there is a hope
>in hell on getting consensus on this issue.
>
>The only solutions I see are:
>---
>Add an extra module that implements sane names.  This would be a
>compile-time option that is disabled by default. Include methods to
>translate scripts between the two naming scheme.  Include tools to make
>coding easier, including Hartmut's handy function looker-upper widget
>(basically, if you use an unknown function name, PHP attempts to recommend a
>proper function name for you to use.)
>
>In the off chance that we can get consensus, either:
> Start a ground up rework of the language for PHP 5.  Audit the source
>code and fix the outstanding gremlins.  I suspect that this has about as
>much chance happening as most of us have of becoming male models.
>
> Implement one of the moderate proposals that many of us have already
>outlined.
>
>Fork the codebase - start a variant called H_P_H (Hypertext
>Preprocessor::Hypocoristic) with sensible names ; )\
>
>In any case, it is 4 in the morning over here and I still have work to do.
>I hope that this makes some sense.
>
>--zak
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For 

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

[Zak Greant]

Phil wrote:
> Ron - whose postings I normally agree with :-) - wrote:

As do I :)

[snip]

> I know that Zak has been doing some experiments along these lines, but has
> also been busy on other projects. Any news to report Zak?

I now have less hair that I did before starting. ;)  Finding sensible
consistent names for the function is somewhat of an undertaking.  I am still
working on it

I have been twiddling away with a few ideas and have come to some
conclusions.

Naming is broken.

Points in case: defined, function_exists, isset and class_exists...

We should have a set of standard verbs that we use for cases like this.  I
would like to see something like:

function_defined
class_defined
var[iable]_defined
constant_defined

We can't agree
==
No consensus on this issue can be reached.

We seem to have several schools of thought on this issue.  Here are my
bitter, narrow, soft-headed and sarcastic views on them:

Deny the existence of a problem :)

There is no problem with the function names. So stop yer whining or we'll
make you use Damian Conway's Lingua::Romana::Perligata instead of PHP.
Well, ok... there may be a problem, but I am not convinced of it.  And if
there were a problem, we need a better way to fix it than has been yet
proposed.

Live in eternal fear of backwards compatibility :)
--
When issues of function renaming arise, frighten all the little hackers with
stories of how the villagers will rise against us if we break backwards
compatibility with PHP 2.

Refuse to relinquish old C function names :)
-
At the first sign of any change to the function names, cling tightly to your
'woogie' and begin to cry. They can't make you give up your woogie - why,
you;'d rather shave off your beard and give up your suspenders than live
life without your woogie.

Bite off more than you can chew :)
-
Attempt to swallow large issues in a single bite and end up choking on your
wishful thinking.  Core developers stand around you and make bets on what
color your face will turn before someone remembers the function name for the
Heimlich manuever (is that apply_heimlich_manuever, heim, heimApp,
windpipe_clear... or was it set_socket_blocking (FALSE)

Expand the scope of the argument :)
--
Expand the argument scope until it encompasses almost every aspect of the
language. Wonder why everone else looks at you like you are a large
cockroach.

Hamstring the discussion :)
-
Ignore the thread til it looks like it is getting somewhere, then unload one
crippling message and retreat from the ensuing carnage.


Seriously, this is a bugger to resolve!  I don't think that there is a hope
in hell on getting consensus on this issue.

The only solutions I see are:
---
Add an extra module that implements sane names.  This would be a
compile-time option that is disabled by default. Include methods to
translate scripts between the two naming scheme.  Include tools to make
coding easier, including Hartmut's handy function looker-upper widget
(basically, if you use an unknown function name, PHP attempts to recommend a
proper function name for you to use.)

In the off chance that we can get consensus, either:
Start a ground up rework of the language for PHP 5.  Audit the source
code and fix the outstanding gremlins.  I suspect that this has about as
much chance happening as most of us have of becoming male models.

Implement one of the moderate proposals that many of us have already
outlined.

Fork the codebase - start a variant called H_P_H (Hypertext
Preprocessor::Hypocoristic) with sensible names ; )\

In any case, it is 4 in the morning over here and I still have work to do.
I hope that this makes some sense.

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

[Phil Driscoll]

Ron - whose postings I normally agree with :-) - wrote:

>Ignoring case, the extension count, and the possible naming styles, is
>as follows:
>word_word_word: 65
>wordwordword: 24
>word_wordword: 21
>
>Some extensions use more than one style, but the one most often
>used is word_word_word. Many functions fit into word_word, which
>is not affected one way or another by observing the most common
>thread in naming.
>
>The standard seems to already be in place.

I'll grant that you have shown that word_word_word is the most popular
format in use, which gives weight to the argument that the underscore should
be how we do it, but this falls far short of a standard because those words
are not obeying sensible rules.
We have a random mix of ext_verb_noun and ext_noun_verb, a mixture of verbs
which do the same job, and a motley assortment of other subtleties on the
end of or inserted into function names. That's before we start looking at
the order of the arguments.

The fact is (with no blame attributed anywhere - the way the software has
evolved has made this more or less inevitable) that the namespace is grossly
self inconsistent. I have to look at the manual much more often than I do
with other languages I use. The business of whether to use underscores or
studly caps is just a matter of personal preference, and it is MUCH more
important to get the language consistent than to bicker about that kind of
detail (which, in extremis, could even be made configurable, or multiple
options supported if a consensus could not be reached).

I know that Zak has been doing some experiments along these lines, but has
also been busy on other projects. Any news to report Zak?

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]