> -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: what should their names be in 4.0.5?
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
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
>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
> 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
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
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
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:
> 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
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>> 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
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
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: [
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
