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 f
v" <[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 al
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 t
Addressed to: Distribution list (see below)
** Reply to note from Ron Chmara <[EMAIL PROTECTED]> Thu, 01 Mar 2001 20:36:38 -0700
>
> Well, then defining "well known" may also become an issue. Well known
> by whom? C programmers? Perl Hackers? Java users?
Yes!
If we are importing their co
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 o
Stanislav Malyshev wrote:
> RC>> It's more legible for the same reason that it's easier (and
> RC>> faster) to read "one two three" than "onetwothree". The human
> RC>> mind can easily tokenize at the appropriate places, when it has
> RC>> a token. Without a token, the string is much harder to par
Just +1 :)
- Original Message -
From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
To: "Ron Chmara" <[EMAIL PROTECTED]>
Cc: "PHP Development" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 1:47 PM
Subject: Re: [
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
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
RC>> It's more legible for the same reason that it's easier (and
RC>> faster) to read "one two three" than "onetwothree". The human
RC>> mind can easily tokenize at the appropriate places, when it has
RC>> a token. Without a token, the string is much harder to parse.
For me, "isalpha" is single t
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 fu
Stanislav Malyshev wrote:
> RC>> read (and comprehended) more easily, so the purpose of the
> RC>> function is less ambiguous. Without them, the name becomes less
> Please explain how presense or absense of underscore makes name more or
> less ambigious. I'm really lost here.
It's more legible fo
Richard Lynch wrote:
> > It HAS to be time for a big tidy up, as it is clearly impossible to 'do
> > the right thing' under current circumstances.
>
> Problem is, what you see as "untidy" programmers with a background in
other
> languages and software packages see as "convenient". :-)
>
> For ever
> It HAS to be time for a big tidy up, as it is clearly impossible to 'do
the
> right thing' under current circumstances.
Problem is, what you see as "untidy" programmers with a background in other
languages and software packages see as "convenient". :-)
For every "newbie" it helps to have consi
>A heated argument seems to be developing, which IMHO makes no sense when we
>are discussing a tiny corner of the language. Yes, function names should be
>consistent, however because the current namespace is such a mess it is
>impossibly to argue the toss on this issue because all we can do is mak
Oops
(X) have an alias if isalpha()
should have read
(X) have an alias of isalpha()
and
it is impossibly to argue
should have read
it is impossible to argue
I appear to have lost my grip on the English language this morning, so who
am I to comment on the PHP language :)
--
Phil Driscoll
Dia
>RFC: what should their names be in 4.0.5?
>
> ( ) stay with ctype_alpha() ...
> (X) switch to ctype_isalpha() ...
> ( ) switch to ctype_isalpha() ... and have ctype_alpha() aliases
> ( ) switch to ctype_is_alpha() ...
> ( ) switch to ctype_is_alpha() ... and have ctype_alpha() aliases
> (X)
RC>> I find it annoying having to look up reference manuals for every
RC>> function, to figure out whether or not I need to use
RC>> underscores, and if so, where in the function name should they
I repeat: if you never though of any function that detemines if the
character is an alphanumeric char
Stanislav Malyshev wrote:
> RC>> I think it is helpful for the PHP user base to be
> RC>> able to comprehend the use of a function based on the name.
> On its name, yes - but not on underscores in it. Do you really think
> anybody will remember/care for those underscores?
Yes.
I find it annoying
One of the below IMO.
Andi
At 10:26 AM 2/26/2001 +0100, Hartmut Holzgraefe wrote:
>RFC: what should their names be in 4.0.5?
>
> ( ) stay with ctype_alpha() ...
> (X) switch to ctype_isalpha() ...
> () switch to ctype_isalpha() ... and have ctype_alpha() aliases
> (X) switch to ctype_is
RC>> "Accident" generally does not have a good meaning here
Hmm... I guess I'm not so good in local slang.
RC>> (AZ,USA)... while we (PHP) may not have a good naming schema for
RC>> all functions, I think it is helpful for the PHP user base to be
RC>> able to comprehend the use of a function bas
Stanislav Malyshev wrote:
> JM>> This is not in line with the other is_* functions. To keep in line with
> If you mean ctype functions, I agree - they all should be is*. If you mean
> is_integer type functions - so what? It's not in line also with
> mysql_num_rows function, so? That's just functio
Stanislav Malyshev wrote:
> JM>> This is not in line with the other is_* functions. To keep in line
with
>
> If you mean ctype functions, I agree - they all should be is*. If you mean
> is_integer type functions - so what? It's not in line also with
> mysql_num_rows function, so? That's just funct
> > -Original Message-
> > From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]]
> > Sent: 26 February 2001 09:52
> > To: Hartmut Holzgraefe
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming
>
JM>> This is not in line with the other is_* functions. To keep in line with
If you mean ctype functions, I agree - they all should be is*. If you mean
is_integer type functions - so what? It's not in line also with
mysql_num_rows function, so? That's just functions from different area,
and the f
> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]]
> Sent: 26 February 2001 09:52
> To: Hartmut Holzgraefe
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming
>
>
> HH>> RFC: wh
HH>> RFC: what should their names be in 4.0.5?
HH>>
HH>> ( ) stay with ctype_alpha() ...
HH>> (X) switch to ctype_isalpha() ...
HH>> ( ) switch to ctype_isalpha() ... and have ctype_alpha() aliases
HH>> ( ) switch to ctype_is_alpha() ...
HH>> ( ) switch to ctype_is_alpha() ... and have c
RFC: what should their names be in 4.0.5?
( ) stay with ctype_alpha() ...
( ) switch to ctype_isalpha() ...
( ) switch to ctype_isalpha() ... and have ctype_alpha() aliases
( ) switch to ctype_is_alpha() ...
( ) switch to ctype_is_alpha() ... and have ctype_alpha() aliases
( )
28 matches
Mail list logo
