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

2001-03-02 Thread 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]




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

2001-03-01 Thread 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 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

2001-03-01 Thread 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 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

2001-03-01 Thread 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 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]




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

2001-02-28 Thread 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 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]