php-general Digest 15 Jan 2007 01:58:07 -0000 Issue 4570
Topics (messages 247069 through 247092):
Re: Normalized Numbers
247069 by: Brian P. Giroux
247070 by: Brian P. Giroux
247071 by: Roman Neuhauser
247072 by: Brian P. Giroux
247074 by: Brian P. Giroux
247080 by: bruce
247082 by: Robert Cummings
247084 by: Brian P. Giroux
247085 by: bruce
247086 by: Jochem Maas
247089 by: Brian P. Giroux
Re: colon in coma [was: Re: [PHP] Anyone would like to test my open source
application http://sourceforge.net/projects/dfo/ ?]
247073 by: Paul Novitski
247090 by: Gert Cuykens
Re: Stripslashes
247075 by: Beauford
247076 by: Beauford
247077 by: Jim Lucas
247088 by: Larry Garfield
247092 by: Jim Lucas
circular dependency between libraries
247078 by: Roman Neuhauser
247083 by: Jochem Maas
Re: Security with dbHost, dbUser, dbPassword
247079 by: tedd
247087 by: Jochem Maas
Re: Anyone would like to test my open source application
http://sourceforge.net/projects/dfo/ ?
247081 by: Gert Cuykens
Re: Hello
247091 by: Chris
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Jochem Maas wrote:
> Brian P. Giroux wrote:
>> I am just learning PHP and as a practical exercise I've been working on
>> a set of functions to process and manipulate what I call "normalized
>> number" (ISBNs, EANs, UPCs, etc...)
>>
>> My ultimate goal is to create a normnum class and child classes for the
>> different types of numbers.
>>
>> Because of my line of work, I am mostly interested in ISBN-10s,
>> ISBN-13s, EANs and UPCs, but it can also be expanded to credit card
>> numbers, Canadian Social Insurance Numbers, and many more.
>>
>> So far I have functions to validate ISBN-10s and EANs although I've run
>> into a bit of a wall with the digit_sum function as explained in the B:
>> section of that functions header comments.
>
> if you want to turn the direction around reverse the string before
> you start the loop:
> http://php.net/manual/en/function.strrev.php
I never thought of turning the string around.
> personally I would turn the string into an array of chars (which you can then
> also
> reverse as need be) and then do a foreach loop on it ('array index'+1 can be
> used
> to determine position) ... personal preference. anyway take a look at these
> functions:
Is there a reason for converting to an array. It seems to me that the
conversion would add more overhead.
> http://php.net/manual/en/function.str-split.php
> http://php.net/array_reverse
> http://php.net/foreach
>> If anyone can help me out with that or provide any other advice about
>> the rest of it, I'd be grateful.
>
> keep commenting all your code to that extent! you do us proud :-)
Thanks, I don't have much choice. I can only work on this every few
days, sometimes every few weeks. If I don't comment I find that I forget
what I was doing :(
Thanks for your input.
>> The file can be found at http://www.senecal.ca/normnums.php.txt
>>
>> Thanks.
--
Brian P. Giroux
--- End Message ---
--- Begin Message ---
Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-01-12 01:57:27 +0100:
>> Brian P. Giroux wrote:
>>> If anyone can help me out with that or provide any other advice about
>>> the rest of it, I'd be grateful.
>>> The file can be found at http://www.senecal.ca/normnums.php.txt
>
>> keep commenting all your code to that extent! you do us proud :-)
>
> I find the *inline* comments superfluous and cluttering the code.
Because of my inexperience, I need the comments to remind me of what I
did a few days prior.
> They don't add any insight, they simply repeat what the code already says
> very succintly:
>
> 1 function is_valid_isbn10_check_digit($cd) {
> 2 // check if th function was passed only a single character
> 3 if(1==strlen($cd)) {
> 4 // check if the digit is a valid ISBN-10 check digit
> 5 if(is_numeric($cd) || 'x'==$cd || 'X'==$cd) {
> 6 return true;
> 7 } else { // the digit is invalid
> 8 return false;
> 9 }
> 10 } else { // the check digit isn't 1 character
> 11 return false;
> 12 }
> 13 }
>
> Comments on lines #2, #4, #7, #10 only restate painfully obvious things.
> Who needs to explain that "13 == strlen($ean)" checks that the length of
> $ean is 13?
>
> This shorter version is more readable for me:
>
> 1 function is_valid_isbn10_check_digit($cd)
> 2 {
> 3 return (1 == strlen($cd)
> 4 && (is_numeric($cd) || 'x'==$cd || 'X'==$cd)
> 5 );
> 6 }
WOW! I knew the functions could be whittled down (although I couldn't
see how) but I never thought it could be just be a single statement.
> The code is quite complicated for no good reason I could see:
>
> 1 function is_valid_ean($ean) {
> 2 //check that the string is 13 characters long
> 3 if(13==strlen($ean)) {
> 4 // make sure all digits are numeric
> 5 if(is_numeric($ean)) {
> 6 if(0==digit_sum($ean,1,1,3)%10) {
> 7 return true;
> 8 } else { return false; }
> 9 } else { return false; }
> 10 } else { return false; }
> 11 }
>
> First step:
>
> 1 function is_valid_ean($ean) {
> 2 if(13==strlen($ean))
> 3 if(is_numeric($ean))
> 4 if(0==digit_sum($ean,1,1,3)%10)
> 5 return true;
> 6 return false;
> 7 }
This makes sense to me, I had forgotten that "return" exits the function
immediately, making the "else" statements unnecessary.
> Second step:
>
> 1 function is_valid_ean($ean) {
> 2 if(13==strlen($ean)
> 3 && is_numeric($ean)
> 4 && (0==digit_sum($ean,1,1,3)%10))
> 5 return true;
> 6 return false;
> 7 }
This also makes sense now that the "else" statements have been removed.
> Third step:
>
> 1 function is_valid_ean($ean) {
> 2 return (13 == strlen($ean)
> 3 && is_numeric($ean)
> 4 && (0 == (digit_sum($ean,1,1,3) % 10))
> 5 );
> 6 }
Again, WOW! This is certainly the version I will use (if you don't mind).
> The last version tells me what I need to know, and tells it only once!
> The three lines are so little of so "uninteresting" code, (there's
> obviously nothing overly complicated going on) that they don't need more
> explanation than a good function name provides.
>
--
Brian P. Giroux
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2007-01-14 10:49:49 -0500:
> > 1 function is_valid_ean($ean) {
> > 2 return (13 == strlen($ean)
> > 3 && is_numeric($ean)
> > 4 && (0 == (digit_sum($ean,1,1,3) % 10))
> > 5 );
> > 6 }
>
> Again, WOW! This is certainly the version I will use (if you don't mind).
Not at all. Also see my other post in this thread, I made more changes
to your code, you're welcome to use anything you find useful.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
--- Begin Message ---
Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-01-12 13:39:59 +0100:
>> Roman Neuhauser wrote:
>>> # [EMAIL PROTECTED] / 2007-01-12 01:57:27 +0100:
>>>> Brian P. Giroux wrote:
>>>>> If anyone can help me out with that or provide any other advice about
>>>>> the rest of it, I'd be grateful.
>>>>> The file can be found at http://www.senecal.ca/normnums.php.txt
>>>> keep commenting all your code to that extent! you do us proud :-)
>>> I find the *inline* comments superfluous and cluttering the code. They
>>> don't add any insight, they simply repeat what the code already says very
>>> succintly:
>> it is anything but superfluous imho - the comment describes what the line of
>> code *should* be doing - given that the code itself maybe changed (and
>> possibly broken)
>
> That's exactly one of the things that make comments dangerous: they can easily
> diverge from the code!
>
> Use lots of small functions, well named, with well defined tasks.
> It's easy to see where the code lies about itself then.
> Use automated tests. You won't need to check whether the code actually
> does what a comment says: the test either succeeded or failed.
I'm with you on that. I love the "modularity" of the language.
> I know it sounds crazy, but (most) comments are evil. Comments are are
> excuses for better code, they're often no more than a vague repetition
> of what the code says. If the code doesn't describe what it's doing
> while it's doing it, then the code should be fixed.
Sounds like someone who is very comfortable with the language. I wanted
to look at some practical examples (something that was actually in use
as opposed to some examples from a book) so I opened up phpmyadmin. It
may as well have been written in a different language. I couldn't figure
it out and there weren't many comments to help me. I hope one day I will
be as comfortable in php as I am in English, but for now, I need the
interpretation found in comments.
> (Re "should": that word actually appears in the documentation comments,
> reducing their utility. "Should" is a human pronounciation of a
> nonexistent operator with undefined semantics, so I had to look at the
> code anyway.)
>
>> the comment serves as a mechanism to check that the specific line of
>> code *actually* does what was intended - with the comment there is no
>> way to know for sure that the logic of the code (even though it may be
>> syntactically correct) does what the original developer *intended*
>
> Comments are a poor tool to find out or enforce anything about code.
> Who put the bugs in? Humans. What makes humans better suited to find
> bugs in the code than computers?
>
>> I have found myself fixing logic bugs in code that I *thought* did what it
>> intended but in reality did something slightly different - related comments
>> help to remind me/you/us/them what the intention was regardless of what
>> was/is
>> actually implemented.
>
> Perhaps the code had some of the bad smells Fowler (w/ Beck, IIRC)
> describes in Refactoring. Also, automated tests would be waaay more
> useful: the bugs wouldn't get in the code in the first place!
>
>>> Comments on lines #2, #4, #7, #10 only restate painfully obvious things.
>>> Who needs to explain that "13 == strlen($ean)" checks that the length of
>>> $ean is 13?
>> consider it not some much an explanation but a statement of intent (see
>> above).
>
> See my objections above as well.
>
> Which line contains a bug?
>
> 4 // check if the digit is a valid ISBN-10 check digit
> 5 if(is_numeric($cd) || 'z'==$cd || 'Z'==$cd) {
>
>> secondly I, personally, find it useful to write a stub function with comments
>> in that describe the various logic steps the function will be doing and then
>> later
>> actually write the code that accomplishes it.
>
> When I want to document a piece of code I turn it into a function.
> I sum up the comment I would have written into that function's name.
>
> If the code needs commenting then it's too complicated, there's not enough
> structure, you're using bad function/variable names, or doing something
> else wrong.
>
>> at the end of the day the ammount of comments written/used is somewhat
>> down to personal preference/requirements. that said comments can't really
>> hurt
>> so long as the content of the comments are accurate!
>
> Yes. What tool (humans introduce bugs, I want something automated) do
> you use to enforce that the code never deviates from the comments?
>
>>> 1 function is_valid_ean($ean) {
>>> 2 return (13 == strlen($ean)
>>> 3 && is_numeric($ean)
>>> 4 && (0 == (digit_sum($ean,1,1,3) % 10))
>>> 5 );
>>> 6 }
>>>
>>> The last version tells me what I need to know, and tells it only once!
>>> The three lines are so little of so "uninteresting" code, (there's
>>> obviously nothing overly complicated going on) that they don't need more
>>> explanation than a good function name provides.
>> I dispute the value you give the comments - obviously the ability of the
>> programmer(s) writing/using the code determines to some extent the level of
>> comments that are useful -
>
> Yes, that's obvious, but there's a bottom. I claim that comments like
> these do the code and programmer no good. Come on, it's just a braindead
>
> 13 == strlen($ean)
>
> Everybody who has trouble understanding that expression raise your hand
> please! ;)
I'm a little embarrassed to say that when I started, that was one of the
things tripping me up, until I read the reason for putting the literal
on the left.
>> from what I gather your (Roman) own skills are quite advanced and as
>> such you probably *require* less in terms of comment feedback in code
>> you use/write.
>
> Thanks for the pat but I don't look my skills too high. For example, my
> skills at keeping comments in sync with the code or my skills at never
> misreading a comment are so poor I write (virtually) all comments in the
> form of code so that the computer can check everything for me. I know I
> cannot trust myself, too many mistakes every day remind me of that.
>
>> I do agree with you premise (& example) that the code can be made alot
>> more compact and thereby (imho) also more managable/readable.
>
> So you agree in the end.
>
--
Brian P. Giroux
Sénécal & Associé.e.s / Associates
Recherche et marketing / Research and marketing
Tél : (705) 476-9667
Fax : (705) 476-1618
www.senecal.ca
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
> On Fri, 2007-01-12 at 14:40 +0000, Roman Neuhauser wrote:
>> I know it sounds crazy, but (most) comments are evil. Comments are are
>> excuses for better code, they're often no more than a vague repetition
>> of what the code says. If the code doesn't describe what it's doing
>> while it's doing it, then the code should be fixed.
>
> Amen.
>
> There are not that many cases were comments are actually useful.
> Generally when necessary they give a brief summary of what is intended
> or they clarify ambiguity or specialized techniques. Well chosen
> variable and function names cause the code to practically comment
> itself.
>
> I think the discipline of using longer and more descriptive
> variable/function/class names is far more helpful than commenting every
> second line of code with the obvious.
>
>>> 2 // check if th function was passed only a single character
>>> 3 if(1==strlen($cd)) {
>
> Ummm, DUH! :)
I guess some of the comments are a little obvious.
> Cheers,
> Rob.
--
Brian P. Giroux
Sénécal & Associé.e.s / Associates
Recherche et marketing / Research and marketing
Tél : (705) 476-9667
Fax : (705) 476-1618
www.senecal.ca
--- End Message ---
--- Begin Message ---
hi...
haven't followed the entire thread.. just saw this portion that pertains to
comments....
i can only assume you guys are relatively young.. if you ever have to pick
up a piece of code that was developed 10 years ago, and you need to track
down/test/get back into production in a matter of a few days, then you had
better pray that the code was either 1) carefully used the variable
declarations in a matter that you understand, or 2) that the code has
copious comments at both the functional level as well as the line/section
level, and that the routines discussed the functions that use the routine,
as well as where the inputs are coming from, and going to...
there's a huge difference in dealing with something that runs a small
website, and something that controls a processing line, where if you screw
it up, you're going to cost $5K/hour when the code is screwing up!!!!
my $0.02 worth....
ps. keep in mind, one person's clear code declarations can be complete
garbage to another person, and you forget why in the hell you did something
over time... clear code comments are a way to (hopefully) make sense of what
the overall chunk of code is supposed to accomplish!!
-----Original Message-----
From: Brian P. Giroux [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 14, 2007 8:30 AM
To: [email protected]
Subject: Re: [PHP] Normalized Numbers
Robert Cummings wrote:
> On Fri, 2007-01-12 at 14:40 +0000, Roman Neuhauser wrote:
>> I know it sounds crazy, but (most) comments are evil. Comments are are
>> excuses for better code, they're often no more than a vague repetition
>> of what the code says. If the code doesn't describe what it's doing
>> while it's doing it, then the code should be fixed.
>
> Amen.
>
> There are not that many cases were comments are actually useful.
> Generally when necessary they give a brief summary of what is intended
> or they clarify ambiguity or specialized techniques. Well chosen
> variable and function names cause the code to practically comment
> itself.
>
> I think the discipline of using longer and more descriptive
> variable/function/class names is far more helpful than commenting every
> second line of code with the obvious.
>
>>> 2 // check if th function was passed only a single character
>>> 3 if(1==strlen($cd)) {
>
> Ummm, DUH! :)
I guess some of the comments are a little obvious.
> Cheers,
> Rob.
--
Brian P. Giroux
Sénécal & Associé.e.s / Associates
Recherche et marketing / Research and marketing
Tél : (705) 476-9667
Fax : (705) 476-1618
www.senecal.ca
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Sun, 2007-01-14 at 11:21 -0800, bruce wrote:
> hi...
>
> haven't followed the entire thread.. just saw this portion that pertains to
> comments....
>
> i can only assume you guys are relatively young.. if you ever have to pick
> up a piece of code that was developed 10 years ago, and you need to track
> down/test/get back into production in a matter of a few days, then you had
> better pray that the code was either 1) carefully used the variable
> declarations in a matter that you understand, or 2) that the code has
> copious comments at both the functional level as well as the line/section
> level, and that the routines discussed the functions that use the routine,
> as well as where the inputs are coming from, and going to...
>
> there's a huge difference in dealing with something that runs a small
> website, and something that controls a processing line, where if you screw
> it up, you're going to cost $5K/hour when the code is screwing up!!!!
>
> my $0.02 worth....
>
> ps. keep in mind, one person's clear code declarations can be complete
> garbage to another person, and you forget why in the hell you did something
> over time... clear code comments are a way to (hopefully) make sense of what
> the overall chunk of code is supposed to accomplish!!
Nobody disagrees with clarifying unclear or ambiguous code. But we do
think it's unnecessary for every single line of obvious code to be
documented. The time it takes to get up to speed in any source code
depends on the quality of the comments, not the quantity. If every
single lines has a comment of the types, /* here we enter the blah
loop /*, /* here we increment the oogley boogley */, /* end of while
loop */, you can be quite sure this amount of copious ridiculous
commenting will increase the noise level and make it difficult to see
what is important. We all know what ++ does, we know what strlen() does,
we generally know what most system functions do. If you have too much
noise in the comments, the reader 5 years down the road is going to miss
important comments because after reading 5 to 10 frivolous comments they
are going to start scanning instead of reading.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Roman Neuhauser wrote:
--
Brian P. Giroux
Sénécal & Associé.e.s / Associates
Recherche et marketing / Research and marketing
Tél : (705) 476-9667
Fax : (705) 476-1618
www.senecal.ca> # [EMAIL PROTECTED] / 2007-01-12 14:40:04 +0000:
>> # [EMAIL PROTECTED] / 2007-01-12 13:39:59 +0100:
>>> Roman Neuhauser wrote:
>>>> # [EMAIL PROTECTED] / 2007-01-12 01:57:27 +0100:
>>>>> Brian P. Giroux wrote:
>>>>>> If anyone can help me out with that or provide any other advice about
>>>>>> the rest of it, I'd be grateful.
>>>>>> The file can be found at http://www.senecal.ca/normnums.php.txt
>>>>> keep commenting all your code to that extent! you do us proud :-)
>>>> I find the *inline* comments superfluous and cluttering the code. They
>>>> don't add any insight, they simply repeat what the code already says very
>>>> succintly:
>>> it is anything but superfluous imho - the comment describes what the line of
>>> code *should* be doing - given that the code itself maybe changed (and
>>> possibly broken)
>> That's exactly one of the things that make comments dangerous: they can
>> easily
>> diverge from the code!
>>
>> Use lots of small functions, well named, with well defined tasks.
>> It's easy to see where the code lies about itself then.
>> Use automated tests. You won't need to check whether the code actually
>> does what a comment says: the test either succeeded or failed.
>
> I converted the original "tests" (they don't evaluate the results,
> that's up to the user) into a few Testilence-based test cases, and then
> modified the code a bit. I removed almost all inline comments to let the
> code come forward and speak for itself, and then reduced the code to
> speak more clearly. It's not something I'd consider finished, but you
> get the idea.
>
> Regarding the digit_sum() "bug", I don't understand why you just don't
> strrev() the input string. You'll need to swap the weights as well if
> the string consists of an even number of characters. There's a test case
> showing this as well.
>
> The tests are really straight conversions of the old ones. I don't think
> they're good, tests should IMO represent boolean questions about the
> code, and provide answers to them. The old tests didn't ask any clear
> questions, this is carried over to the new ones.
>
> You can see my version at http://codex.sigpipe.cz/tmp/normnums.phps,
> Testilence is at http://www.testilence.org/.
I tried to install Testilence on my Ubuntu using Gnu make 3.81beta4(my
skills as a Linux administrator are weaker than my PHP skills) but was
unsuccessful :(
I love the idea of being able to test the test functions "here is what
the result should be" and having it compare with what it actually does.
I hope to be able to install it at a later time when my skills improve.
I will however use your improvements on the functions right now.
--
Brian P. Giroux
--- End Message ---
--- Begin Message ---
hey rob..
like i said.. hadn't followed the thread...
and yes, i too would say commenting every 2-3 lines is pretty much a waste..
for production code, my rule of thumb, and something i've 'encouraged'
people working for me, was/is ~100 lines of code (max) for a routine... this
varies, but it's about what you can easily read up/down in an editor on a
screen, without having to scan back/forth..
but i also encourage developers who are implementing any serious
algorithms/calculations to damn sure insert their assumptions, or to point
to external docs that explain things in more specific detail.
just part of the working product.
peace...
-----Original Message-----
From: Robert Cummings [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 14, 2007 11:45 AM
To: [EMAIL PROTECTED]
Cc: 'Brian P. Giroux'; [email protected]
Subject: RE: [PHP] Normalized Numbers
On Sun, 2007-01-14 at 11:21 -0800, bruce wrote:
> hi...
>
> haven't followed the entire thread.. just saw this portion that pertains
to
> comments....
>
> i can only assume you guys are relatively young.. if you ever have to pick
> up a piece of code that was developed 10 years ago, and you need to track
> down/test/get back into production in a matter of a few days, then you had
> better pray that the code was either 1) carefully used the variable
> declarations in a matter that you understand, or 2) that the code has
> copious comments at both the functional level as well as the line/section
> level, and that the routines discussed the functions that use the routine,
> as well as where the inputs are coming from, and going to...
>
> there's a huge difference in dealing with something that runs a small
> website, and something that controls a processing line, where if you screw
> it up, you're going to cost $5K/hour when the code is screwing up!!!!
>
> my $0.02 worth....
>
> ps. keep in mind, one person's clear code declarations can be complete
> garbage to another person, and you forget why in the hell you did
something
> over time... clear code comments are a way to (hopefully) make sense of
what
> the overall chunk of code is supposed to accomplish!!
Nobody disagrees with clarifying unclear or ambiguous code. But we do
think it's unnecessary for every single line of obvious code to be
documented. The time it takes to get up to speed in any source code
depends on the quality of the comments, not the quantity. If every
single lines has a comment of the types, /* here we enter the blah
loop /*, /* here we increment the oogley boogley */, /* end of while
loop */, you can be quite sure this amount of copious ridiculous
commenting will increase the noise level and make it difficult to see
what is important. We all know what ++ does, we know what strlen() does,
we generally know what most system functions do. If you have too much
noise in the comments, the reader 5 years down the road is going to miss
important comments because after reading 5 to 10 frivolous comments they
are going to start scanning instead of reading.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Brian P. Giroux wrote:
>
> Jochem Maas wrote:
>> Brian P. Giroux wrote:
>>> I am just learning PHP and as a practical exercise I've been working on
>>> a set of functions to process and manipulate what I call "normalized
>>> number" (ISBNs, EANs, UPCs, etc...)
>>>
>>> My ultimate goal is to create a normnum class and child classes for the
>>> different types of numbers.
>>>
>>> Because of my line of work, I am mostly interested in ISBN-10s,
>>> ISBN-13s, EANs and UPCs, but it can also be expanded to credit card
>>> numbers, Canadian Social Insurance Numbers, and many more.
>>>
>>> So far I have functions to validate ISBN-10s and EANs although I've run
>>> into a bit of a wall with the digit_sum function as explained in the B:
>>> section of that functions header comments.
>> if you want to turn the direction around reverse the string before
>> you start the loop:
>> http://php.net/manual/en/function.strrev.php
>
> I never thought of turning the string around.
you can't be expected to know everything, especially not when starting out ...
that said just browsing the manual for it's own sake is to be recommended,
not exactly a rollercoaster read but you'll be surprised at the ammount of stuff
you can pick up.
>
>> personally I would turn the string into an array of chars (which you can
>> then also
>> reverse as need be) and then do a foreach loop on it ('array index'+1 can be
>> used
>> to determine position) ... personal preference. anyway take a look at these
>> functions:
>
> Is there a reason for converting to an array. It seems to me that the
> conversion would add more overhead.
noo not really - more of a preference on my part, I prefer foreach() to for()
when I have the choice and I usually find that the code is compacter when using
foreach(), it also [often] mitigates the need to keep track of a counter
variable.
>
>> http://php.net/manual/en/function.str-split.php
>> http://php.net/array_reverse
>> http://php.net/foreach
>>> If anyone can help me out with that or provide any other advice about
>>> the rest of it, I'd be grateful.
>> keep commenting all your code to that extent! you do us proud :-)
>
> Thanks, I don't have much choice. I can only work on this every few
> days, sometimes every few weeks. If I don't comment I find that I forget
> what I was doing :(
making sure your comments are accurate is paramount, undoubtly your need to
comment things will become less as your skills improve.
as Roman pointed out comments have their downside too - I'm certainly taking
what he's said and am digging into his Testilence tool.
at the end of the day it's all about learning, improving and sharing your
skills :-)
--- End Message ---
--- Begin Message ---
Arpad Ray wrote:
> Have you checked out the PEAR Validate packages?
> http://pear.php.net/package/Validate_ISPN in particular might help you
> along ;)
I figured that someone had probably done this before. I wanted to do it
myself because I figured it's a nice simple exercise to get my feet wet,
and it's something I will probably use (unlike something from a book).
> And BTW, most servers are set up to display php files renamed to .phps
> with syntax highlighting, so give that a try instead of .php.txt next time.
This is good to know, I've tried it on the senecal.ca server a Microsoft
IIS) and it doesn't seem to work. I think I have some space on another
server, I'll have to dig up the username and password and give it a try.
> Regards,
>
> Arpad
>
> Brian P. Giroux wrote:
>> I am just learning PHP and as a practical exercise I've been working on
>> a set of functions to process and manipulate what I call "normalized
>> number" (ISBNs, EANs, UPCs, etc...)
>>
>> My ultimate goal is to create a normnum class and child classes for the
>> different types of numbers.
>>
>> Because of my line of work, I am mostly interested in ISBN-10s,
>> ISBN-13s, EANs and UPCs, but it can also be expanded to credit card
>> numbers, Canadian Social Insurance Numbers, and many more.
>>
>> So far I have functions to validate ISBN-10s and EANs although I've run
>> into a bit of a wall with the digit_sum function as explained in the B:
>> section of that functions header comments.
>>
>> If anyone can help me out with that or provide any other advice about
>> the rest of it, I'd be grateful.
>>
>> The file can be found at http://www.senecal.ca/normnums.php.txt
>>
>> Thanks.
>>
--
Brian P. Giroux
--- End Message ---
--- Begin Message ---
, comma
; semicolon
: colon
http://www.usask.ca/its/courses/cai/javascript/js_semicolon.html
http://en.wikipedia.org/wiki/Punctuation
http://www.cogs.susx.ac.uk/doc/punctuation/node00.html
--- End Message ---
--- Begin Message ---
lol :)
Anyway did you guys tried it yet ?
--- End Message ---
--- Begin Message ---
I guess I'm just doing something wrong, 'cause that doesn't work either -
nor do the hundreds of other snippets I've used.
Here's the scenario. I have a form - after they submit the form it shows
what they have entered, this is where I get the \. It also does it if the
form redisplays after the user has input invalid data.
All this is being done on the same page.
> -----Original Message-----
> From: Jim Lucas [mailto:[EMAIL PROTECTED]
> Sent: January 14, 2007 1:02 AM
> To: Beauford
> Cc: PHP
> Subject: Re: [PHP] Stripslashes
>
> Beauford wrote:
> > Hi,
> >
> > Anyone know how I can strip slashes from $_POST variables. I have
> > tried about a hundred different ways of doing this and
> nothing works.
> >
> > i.e.
> >
> > if(!empty($_POST)){
> > foreach($_POST as $x => $y){
> > $_POST[$x] = stripslashes($y);
> > }
> > }
> >
> > This came about after someone tried to enter O'Toole in a
> form, and it
> > appeared as O\'Toole.
> >
> > Thanks
> >
> >
> This is what I use, and it has worked ever time.
>
> if ( get_magic_quotes_gpc() ) {
> $_POST = array_map("stripslashes", $_POST); }
>
> Jim Lucas
>
>
>
--- End Message ---
--- Begin Message ---
I just turned off get_magic_quotes in my PHP.ini, but not sure if the
hosting company has it on or not once I upload the site.
> -----Original Message-----
> From: Beauford [mailto:[EMAIL PROTECTED]
> Sent: January 14, 2007 11:34 AM
> To: 'PHP'
> Subject: RE: [PHP] Stripslashes
>
>
> I guess I'm just doing something wrong, 'cause that doesn't
> work either - nor do the hundreds of other snippets I've used.
>
> Here's the scenario. I have a form - after they submit the
> form it shows what they have entered, this is where I get the
> \. It also does it if the form redisplays after the user has
> input invalid data.
>
> All this is being done on the same page.
>
> > -----Original Message-----
> > From: Jim Lucas [mailto:[EMAIL PROTECTED]
> > Sent: January 14, 2007 1:02 AM
> > To: Beauford
> > Cc: PHP
> > Subject: Re: [PHP] Stripslashes
> >
> > Beauford wrote:
> > > Hi,
> > >
> > > Anyone know how I can strip slashes from $_POST variables. I have
> > > tried about a hundred different ways of doing this and
> > nothing works.
> > >
> > > i.e.
> > >
> > > if(!empty($_POST)){
> > > foreach($_POST as $x => $y){
> > > $_POST[$x] = stripslashes($y);
> > > }
> > > }
> > >
> > > This came about after someone tried to enter O'Toole in a
> > form, and it
> > > appeared as O\'Toole.
> > >
> > > Thanks
> > >
> > >
> > This is what I use, and it has worked ever time.
> >
> > if ( get_magic_quotes_gpc() ) {
> > $_POST = array_map("stripslashes", $_POST); }
> >
> > Jim Lucas
> >
> >
> >
>
> --
> PHP General Mailing List (http://www.php.net/) To
> unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--- End Message ---
--- Begin Message ---
Beauford wrote:
I just turned off get_magic_quotes in my PHP.ini, but not sure if the
hosting company has it on or not once I upload the site.
-----Original Message-----
From: Beauford [mailto:[EMAIL PROTECTED]
Sent: January 14, 2007 11:34 AM
To: 'PHP'
Subject: RE: [PHP] Stripslashes
I guess I'm just doing something wrong, 'cause that doesn't
work either - nor do the hundreds of other snippets I've used.
Here's the scenario. I have a form - after they submit the
form it shows what they have entered, this is where I get the
\. It also does it if the form redisplays after the user has
input invalid data.
All this is being done on the same page.
-----Original Message-----
From: Jim Lucas [mailto:[EMAIL PROTECTED]
Sent: January 14, 2007 1:02 AM
To: Beauford
Cc: PHP
Subject: Re: [PHP] Stripslashes
Beauford wrote:
Hi,
Anyone know how I can strip slashes from $_POST variables. I have
tried about a hundred different ways of doing this and
nothing works.
i.e.
if(!empty($_POST)){
foreach($_POST as $x => $y){
$_POST[$x] = stripslashes($y);
}
}
This came about after someone tried to enter O'Toole in a
form, and it
appeared as O\'Toole.
Thanks
This is what I use, and it has worked ever time.
if ( get_magic_quotes_gpc() ) {
$_POST = array_map("stripslashes", $_POST); }
Jim Lucas
--
PHP General Mailing List (http://www.php.net/) To
unsubscribe, visit: http://www.php.net/unsub.php
do you have a way to look at the data in the DB, if so, look to see if
the back slashes are in the db
--- End Message ---
--- Begin Message ---
On a real web host, they'll let you have a .htaccess file where you can
disable them like so:
php_value magic_quotes_gpc 0
(I keep saying "real web host" because I've just recently had to deal with a
few web hosts that a client insisted on that didn't have a standard
configuration and didn't support .htaccess files. I lost 6 hours of my life
right before Christmas trying to work around that fact, and I can't get them
back. If you find yourself in the same situation, vote with your feet and
let such hosts die a horrible and bankrupt death.)
On Sunday 14 January 2007 10:46 am, Beauford wrote:
> I just turned off get_magic_quotes in my PHP.ini, but not sure if the
> hosting company has it on or not once I upload the site.
>
> > -----Original Message-----
> > From: Beauford [mailto:[EMAIL PROTECTED]
> > Sent: January 14, 2007 11:34 AM
> > To: 'PHP'
> > Subject: RE: [PHP] Stripslashes
> >
> >
> > I guess I'm just doing something wrong, 'cause that doesn't
> > work either - nor do the hundreds of other snippets I've used.
> >
> > Here's the scenario. I have a form - after they submit the
> > form it shows what they have entered, this is where I get the
> > \. It also does it if the form redisplays after the user has
> > input invalid data.
> >
> > All this is being done on the same page.
> >
> > > -----Original Message-----
> > > From: Jim Lucas [mailto:[EMAIL PROTECTED]
> > > Sent: January 14, 2007 1:02 AM
> > > To: Beauford
> > > Cc: PHP
> > > Subject: Re: [PHP] Stripslashes
> > >
> > > Beauford wrote:
> > > > Hi,
> > > >
> > > > Anyone know how I can strip slashes from $_POST variables. I have
> > > > tried about a hundred different ways of doing this and
> > >
> > > nothing works.
> > >
> > > > i.e.
> > > >
> > > > if(!empty($_POST)){
> > > > foreach($_POST as $x => $y){
> > > > $_POST[$x] = stripslashes($y);
> > > > }
> > > > }
> > > >
> > > > This came about after someone tried to enter O'Toole in a
> > >
> > > form, and it
> > >
> > > > appeared as O\'Toole.
> > > >
> > > > Thanks
> > >
> > > This is what I use, and it has worked ever time.
> > >
> > > if ( get_magic_quotes_gpc() ) {
> > > $_POST = array_map("stripslashes", $_POST); }
> > >
> > > Jim Lucas
> >
> > --
> > PHP General Mailing List (http://www.php.net/) To
> > unsubscribe, visit: http://www.php.net/unsub.php
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--- End Message ---
--- Begin Message ---
Beauford wrote:
I just turned off get_magic_quotes in my PHP.ini, but not sure if the
hosting company has it on or not once I upload the site.
What do you mean by "my PHP.ini" file? Are you saying that php is
running as a cgi or as an apache mod?
-----Original Message-----
From: Beauford [mailto:[EMAIL PROTECTED]
Sent: January 14, 2007 11:34 AM
To: 'PHP'
Subject: RE: [PHP] Stripslashes
I guess I'm just doing something wrong, 'cause that doesn't
work either - nor do the hundreds of other snippets I've used.
Here's the scenario. I have a form - after they submit the
form it shows what they have entered, this is where I get the
\. It also does it if the form redisplays after the user has
input invalid data.
All this is being done on the same page.
-----Original Message-----
From: Jim Lucas [mailto:[EMAIL PROTECTED]
Sent: January 14, 2007 1:02 AM
To: Beauford
Cc: PHP
Subject: Re: [PHP] Stripslashes
Beauford wrote:
Hi,
Anyone know how I can strip slashes from $_POST variables. I have
tried about a hundred different ways of doing this and
nothing works.
i.e.
if(!empty($_POST)){
foreach($_POST as $x => $y){
$_POST[$x] = stripslashes($y);
}
}
This came about after someone tried to enter O'Toole in a
form, and it
appeared as O\'Toole.
Thanks
This is what I use, and it has worked ever time.
if ( get_magic_quotes_gpc() ) {
$_POST = array_map("stripslashes", $_POST); }
Jim Lucas
--
PHP General Mailing List (http://www.php.net/) To
unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
I have a circular dependency, and am looking for thoughts on breaking
the cycle without (much) redundancy or hard to automate procedures.
I'm developing two programs, Testilence, a unit testing library, and
Amock (library for mock object generation, but that's irrelevant in this
discussion); both programs have unit tests based on Testilence, but
Amock itself should not depend on Testilence, and neither should contain
(or depend on) nontested code.
Testilence contains some utility classes I'd like to use in Amock (or
indeed, anywhere). I could "fork" them, but would like to avoid this
if at all possible. I think I can't pull them out into a separate
library for both Amock and Testilence to depend on because that would
create a dependency loop between the utility and Testilence since I'd
like to keep using Testilence for the utility's unit tests.
Both Amock and Testilence are versioned using Subversion, so I could
leave the classes in Testilence and use svn:externals to put them in
Amock too. That would lead to name clashes if both programs were used
together, and that is a showstopper.
Any ideas?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
--- Begin Message ---
Roman Neuhauser wrote:
> I have a circular dependency, and am looking for thoughts on breaking
> the cycle without (much) redundancy or hard to automate procedures.
>
> I'm developing two programs, Testilence, a unit testing library, and
> Amock (library for mock object generation, but that's irrelevant in this
> discussion); both programs have unit tests based on Testilence, but
> Amock itself should not depend on Testilence, and neither should contain
> (or depend on) nontested code.
>
> Testilence contains some utility classes I'd like to use in Amock (or
> indeed, anywhere). I could "fork" them, but would like to avoid this
> if at all possible. I think I can't pull them out into a separate
> library for both Amock and Testilence to depend on because that would
> create a dependency loop between the utility and Testilence since I'd
> like to keep using Testilence for the utility's unit tests.
isn't there a circular dependency anyway? given that you unit test
Testilence with Testilence?
if these utility classes are utility classes I wonder whether it's not better
if they have no external dependencies?
whilst reading about Testilence I remember coming across a mention of runkit
... whilst I wonder whether using runkit for anything other than experimental
stuff, could runkit not offer a solution (e.g. renaming the class dependent on
the context of it's usage)? probably not, right?
>
> Both Amock and Testilence are versioned using Subversion, so I could
> leave the classes in Testilence and use svn:externals to put them in
> Amock too. That would lead to name clashes if both programs were used
> together, and that is a showstopper.
given that they are the same code would conditional loading of the utlity
classes not work? i.e. only load if they don't already exist, this could
be augemented with the use of a [number of] Interfaces - if the class already
exists and doesn't implement the required interfaces then your code bails out.
obviously someone could write classes and interfaces that spoof your actual
code/classes/interfaces but then there must a be limit to what your code
should/can
check for/against. where there is doubt suitable warning can always be
generated.
at the end of the day your tools are meant to aid developers, in that sense
it might be considered acceptable to assume the developer won't purposefully try
and break your tools - he/she would only be hurting themselves, no?
>
> Any ideas?
not really ;-)
what exactly do these utility classes do?
can you point us at a link?
>
--- End Message ---
--- Begin Message ---
At 12:43 PM +0100 1/11/07, Jochem Maas wrote:
Satyam wrote:
No problem there, the include in my DB abstraction layer includes and
calls the separate file with the function to make the connection to the
database. Though the main application source doesn't know about the
include file with the connection data in it, the DB layer include
does. In this way, I have the db include file under CVS and can
refresh it at the production server without a problem, while the include
file with the connection is separate, so that I have one for the test
machine (this one) where the server is 'localhost' which I never copy to
the production server.
there are many way to skin the cat :-)
... but the cat ain't going to like any of them -- Jeff Foxworthy
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
tedd wrote:
> At 12:43 PM +0100 1/11/07, Jochem Maas wrote:
>> Satyam wrote:
>>
>>> No problem there, the include in my DB abstraction layer includes and
>>> calls the separate file with the function to make the connection to the
>>> database. Though the main application source doesn't know about the
>>> include file with the connection data in it, the DB layer include
>>> does. In this way, I have the db include file under CVS and can
>>> refresh it at the production server without a problem, while the
>>> include
>>> file with the connection is separate, so that I have one for the test
>>> machine (this one) where the server is 'localhost' which I never
>>> copy to
>>> the production server.
>>
>> there are many way to skin the cat :-)
>
> ... but the cat ain't going to like any of them -- Jeff Foxworthy
lol - I hesitate to say 'f*** the cat' but the cat probably wouldn't
like that either ;-)
>
> tedd
--- End Message ---
--- Begin Message ---
Added db5c29 it includes a new server memory login module some small
layout and code modifications.
--- End Message ---
--- Begin Message ---
Edward wrote:
How do I create a php document so that people in my nonprofit can vote
on issues online through the organization's website?
Search google for 'php voting script' or some such variant, I'm sure
there are lots of them available.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
