php-general-digest-helplists.php.net
Date: Wed May 30 2007 - 15:43:24 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

php-general Digest 30 May 2007 20:43:24 -0000 Issue 4820

Topics (messages 255785 through 255869):

checkboxes problem
        255785 by: blueboy
        255787 by: Zoltán Németh
        255834 by: Richard Lynch

Sessions VS MySQL
        255786 by: Matt Fielding
        255788 by: Darren Whitlen
        255833 by: Richard Lynch
        255846 by: Matt Fielding

Return or not to return, that is the question
        255789 by: Richard Davey
        255791 by: M. Sokolewicz
        255792 by: Edward Kay
        255793 by: Dave Goodchild
        255794 by: Richard Davey
        255795 by: Paul Scott
        255796 by: Zoltán Németh
        255799 by: Chris Boget
        255801 by: Richard Davey
        255802 by: Darren Whitlen
        255803 by: Jay Blanchard
        255807 by: Richard Lynch
        255813 by: Paul Novitski
        255814 by: Jared Farrish
        255815 by: Richard Davey
        255819 by: Richard Davey
        255820 by: Jared Farrish
        255821 by: Paul Novitski
        255826 by: Richard Lynch
        255827 by: Satyam
        255828 by: Jared Farrish
        255829 by: Richard Lynch
        255830 by: Richard Lynch
        255832 by: Richard Lynch
        255840 by: Paul Novitski
        255842 by: Robert Cummings
        255867 by: Philip Thompson

Re: php via cmdline including unwanted headers
        255790 by: Sebe
        255805 by: Robert Cummings
        255835 by: Richard Lynch
        255836 by: Richard Lynch

scheduling a script to check a directory for files
        255797 by: Bosky, Dave
        255800 by: Auto-Deppe, C. Haensel
        255804 by: Marc Weber
        255806 by: Richard Lynch
        255816 by: Jared Farrish

Query Regarding How to contribute towards a bug fix: Sachin
        255798 by: Sachin mahajan

uploading really big files
        255808 by: Angelo Zanetti
        255810 by: Tijnema
        255811 by: Zoltán Németh
        255825 by: Richard Lynch

Best way to convert Little-Endian DWORD to string
        255809 by: Tijnema
        255817 by: Edward Kay
        255818 by: Tijnema
        255824 by: Richard Lynch

Re: Too many records to display in one web page
        255812 by: Steve

Re: ini_set() security question
        255822 by: Richard Lynch
        255851 by: Samuel Vogel
        255854 by: Richard Lynch
        255855 by: Samuel Vogel
        255862 by: Richard Lynch
        255866 by: Samuel Vogel

Re: imap_headerinfo->date
        255823 by: Richard Lynch

preg_match() returns false but no documentation why
        255831 by: Jared Farrish
        255838 by: Richard Lynch
        255859 by: Jared Farrish
        255860 by: Stut
        255861 by: Richard Lynch
        255863 by: Jared Farrish

Re: OOB problem, super stumped. (resolved)
        255837 by: Richard Lynch

Re: Streaming download to IE doesn't work
        255839 by: Richard Lynch
        255841 by: Richard Lynch

Re: Client does not support authentication protocol...
        255843 by: Richard Lynch

Re: a question on session ID and security
        255844 by: Richard Lynch
        255845 by: Richard Lynch
        255847 by: Richard Lynch
        255856 by: Jared Farrish

Re: php execute command on server
        255848 by: Richard Lynch

Re: exec dont work for svn
        255849 by: Richard Lynch
        255850 by: Richard Lynch

Re: Unknown number of check boxes?
        255852 by: Richard Lynch

Re: Tracking exit links with php?
        255853 by: Richard Lynch

Re: using mysql_escape_string with implode() !!
        255857 by: Richard Lynch
        255858 by: Richard Lynch

find (matching) person in other table
        255864 by: Afan Pasalic
        255869 by: Jared Farrish

Re: Form Validation Issues
        255865 by: Richard Lynch

Re: setting windows folder to chmod 644
        255868 by: Richard Lynch

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscribelists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscribelists.php.net

To post to the list, e-mail:
        php-generallists.php.net

----------------------------------------------------------------------

attached mail follows:

Hi,

I have a checkbox array (about 20 lines)

input name=\"box\" type=\"checkbox\" value=\"$id\">
input name=\"box\" type=\"checkbox\" value=\"$id\">
input name=\"box\" type=\"checkbox\" value=\"$id\">

I do some client side checking with javascript however the javascript array

name=\"box\"

does not match the php version,

 name=\"box[]\"

 So either my client side stuff works or the php array only returns 1 value
when posted. Is there any way to for this to work?

R.

attached mail follows:

2007. 05. 30, szerda keltezéssel 09.59-kor blueboy ezt írta:
> Hi,
>
> I have a checkbox array (about 20 lines)
>
> input name=\"box\" type=\"checkbox\" value=\"$id\">
> input name=\"box\" type=\"checkbox\" value=\"$id\">
> input name=\"box\" type=\"checkbox\" value=\"$id\">

input name=\"box[]\" type=\"checkbox\" value=\"$id\">

greets
Zoltán Németh

>
> I do some client side checking with javascript however the javascript array
>
> name=\"box\"
>
> does not match the php version,
>
> name=\"box[]\"
>
> So either my client side stuff works or the php array only returns 1 value
> when posted. Is there any way to for this to work?
>
>
> R.
>

attached mail follows:

On Wed, May 30, 2007 3:59 am, blueboy wrote:
> Hi,
>
> I have a checkbox array (about 20 lines)
>
> input name=\"box\" type=\"checkbox\" value=\"$id\">
> input name=\"box\" type=\"checkbox\" value=\"$id\">
> input name=\"box\" type=\"checkbox\" value=\"$id\">
>
> I do some client side checking with javascript however the javascript
> array
>
> name=\"box\"
>
> does not match the php version,
>
> name=\"box[]\"
>
> So either my client side stuff works or the php array only returns 1
> value
> when posted. Is there any way to for this to work?

Let PHP use the NAME= attribute, and JS use the ID= attribute

name="box[1]" id="box1"

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

I've recently begun work on a web-based RPG game with some friends, and have
recently been thinking about the best solution for loading and saving
persistent variables like player life/stats and other information. I am both
familiar with sessions and mysql for saving and loading variables, and
that's not my question, but I am instead interested in which method would be
more efficient to use. If the data is getting reloaded on each individual
page, would it be more efficient on the system hosting the game to save
certain numbers and variables in a session, or to reaccess the database each
time it needs those numbers.

My biggest concern with using sessions, is if someone were to exit the
browser mid saves to the database, all information would be lost. Since it
is web-based, there is no real way for me to be able to expect everyone to
follow certain procedures to load/save, and I would really like to stay away
from that as well, as it's not as user-friendly and intuitive as an
auto-save feature. I guess my main question here is, are there ways to
auto-save and guarantee data wouldn't be lost without having to load, read,
write, and close a connection to mysql on each page load?

I appreciate any tips, insight, thoughts, stories, or help in absolutely any
fashion that I can get. Even a tip of a nature outside my question related
to my project would be great. it's my first project of this kind, and I'd
like to avoid any problems I can, so I'm putting a lot of forethought into
it all. Also, I'm the only coder, so to have to go back and rewrite a ton of
code from one save method to another is just way too much work.

attached mail follows:

Matt Fielding wrote:
> I've recently begun work on a web-based RPG game with some friends, and
> have
> recently been thinking about the best solution for loading and saving
> persistent variables like player life/stats and other information. I am
> both
> familiar with sessions and mysql for saving and loading variables, and
> that's not my question, but I am instead interested in which method
> would be
> more efficient to use. If the data is getting reloaded on each individual
> page, would it be more efficient on the system hosting the game to save
> certain numbers and variables in a session, or to reaccess the database
> each
> time it needs those numbers.
>
> My biggest concern with using sessions, is if someone were to exit the
> browser mid saves to the database, all information would be lost. Since it
> is web-based, there is no real way for me to be able to expect everyone to
> follow certain procedures to load/save, and I would really like to stay
> away
> from that as well, as it's not as user-friendly and intuitive as an
> auto-save feature. I guess my main question here is, are there ways to
> auto-save and guarantee data wouldn't be lost without having to load, read,
> write, and close a connection to mysql on each page load?

Seems as you don't know if the user will close the browser between page
loads, AND to be user friendly so that they don't have to click a save
button, the ONLY way would be to save the game every time the page loads.

So save all data to the database each page run. This will also help in
that other players will beble use that data. Say if you needed the top
scoring 10 players for example, the data is already saved in the
database so it will be easy to find that out, with the most up-to date
player data.

Darren

>
> I appreciate any tips, insight, thoughts, stories, or help in absolutely
> any
> fashion that I can get. Even a tip of a nature outside my question related
> to my project would be great. it's my first project of this kind, and I'd
> like to avoid any problems I can, so I'm putting a lot of forethought into
> it all. Also, I'm the only coder, so to have to go back and rewrite a
> ton of
> code from one save method to another is just way too much work.
>

attached mail follows:

On Wed, May 30, 2007 4:00 am, Matt Fielding wrote:
> I've recently begun work on a web-based RPG game with some friends,
> and have
> recently been thinking about the best solution for loading and saving
> persistent variables like player life/stats and other information. I
> am both
> familiar with sessions and mysql for saving and loading variables, and
> that's not my question, but I am instead interested in which method
> would be
> more efficient to use. If the data is getting reloaded on each
> individual
> page, would it be more efficient on the system hosting the game to
> save
> certain numbers and variables in a session, or to reaccess the
> database each
> time it needs those numbers.
>
> My biggest concern with using sessions, is if someone were to exit the
> browser mid saves to the database, all information would be lost.
> Since it
> is web-based, there is no real way for me to be able to expect
> everyone to
> follow certain procedures to load/save, and I would really like to
> stay away
> from that as well, as it's not as user-friendly and intuitive as an
> auto-save feature. I guess my main question here is, are there ways to
> auto-save and guarantee data wouldn't be lost without having to load,
> read,
> write, and close a connection to mysql on each page load?
>
> I appreciate any tips, insight, thoughts, stories, or help in
> absolutely any
> fashion that I can get. Even a tip of a nature outside my question
> related
> to my project would be great. it's my first project of this kind, and
> I'd
> like to avoid any problems I can, so I'm putting a lot of forethought
> into
> it all. Also, I'm the only coder, so to have to go back and rewrite a
> ton of
> code from one save method to another is just way too much work.

There are several approaches you could take, and you may even want to
consider a mix of approaches.

The first question is how much this has to scale, and how much data is
stored per user?

Becuase if you need a Meg per user and expect to scale out to XBox,
then you've got a very different problem than if you expect you and
your 10 buddies to be playing this RPG for years on end, but that's
about it...

You may want to classify data into broad buckets such as:
Transient Data - store it in the cookie value
Active Data - store it in session
Permanent Data - auto-save to database
Background Data - the "game" state as opposed to the individual user
state

You might choose to auto-save at certain mile-markers, such as every
time the player gains an experience point, or achieves a specific goal
in the game, or both. (Got the key, rescued the princess, whatever)
Probably be best to have a simple "save" function to call, and call it
as often as needed.

You may also need to consider solving a "Race Condition" within the
saved states -- At some point, you have to purge a saved state if a
user is "gone" long emough and the others had to move forward...
Either that, or suddenly both Biblo *and* Gandalf has "the key" and
your game is all messed up...

There may be some OpenSource RPG engines you could research, or even
link in to PHP as a custom extension -- or throw it into PECL if
enough users want to write RPGs in PHP :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

As far as scalability goes, there's actually a game we're referencing a lot
to help us make it work at the get go called Kingdom of Loathing (
http://www.kingdomofloathing.com ). This game seems to have on average
around 1,000-1,500 users on at any given time. I've noticed when visiting
the page also, that is sends you to a random mirror of the site such as
www2..., www3..., etc.. I'm not sure if those shows that it's directing
people to various servers for the website, and that the database is possibly
stored on one server by itself. This seems a bit bulky a solution for an
online text/2d low res image rpg game, even with 1,000 users playing
simultaneously.

The point of saving only when I need to I get, and was planning to
implement. Such things as exploring around the game world, and, well, that's
all really, don't need to be saved as you'll start at the main location each
time you log in, but other things like battle, buying/selling/upgrading
items and inventory, and quest locations on the map, all need to be saved.

I guess one of my bigger concerns about saving is if it would seem natural
or strange to have it only save after the end of each battle, because the
way the battle system is planned to work is that you attack, it loads the
page, says how much dmg you did and the enemy did, then you may have to
attack again, loading the page howveer many more times is needed until you
die, or the enemy dies. There will be a function to run built in, but aside
from that the only other way to get out is to exit the browser. It seems a
bit cumbersome to have to access the db everytime an attack takes place, but
at the same time the player will be limited to a number of "moves" per day,
to make the game more fun, and help the server from dying. From what I
recall, mysql database calls take only .002 seconds, or something very quick
like that, so I suppose I shouldn't be too worried about the database
overloading from people using it, or should I? That's really one of my main
concerns.

Anyways, thanks for all the help and input so far, it's greatly appreciated.

attached mail follows:

Hi all,

Just a quick straw-poll really:

What is your take on using 'return' when you end a function, if you
don't actually need to return a value?

If you have to return say a true/false as the result of an operation,
then it's an obvious choice. But what if all the function does is
perform an action and then quit? Do you like to use 'return' at the
end of it anyway, or do you just let it run into the closing } ?

Or do you perhaps do a 'return true' at the end, regardless, even if
the rest of your code never checks that value (on the basis that it
may do in the future)

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

attached mail follows:

Richard Davey wrote:
> Hi all,
>
> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)
>
> Cheers,
>
> Rich

In such cases it depends on the project I'm working on. If it's a
slightly bigger project which will see future development, I usually
stick to a return true|false policy even though such functions don't
have a meaningful return (YET!), as this might change later.
If it's a project which will be used but probably won't see any
extensive future development, I generally tend to not return anything.

- Tul

attached mail follows:

> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)
>

I like to have all my functions return something so use return true.

Edward

attached mail follows:

If there is no need to return a value then I don't do so. However, the
function is going to process something, and surely you should check that the
processing has succeeded or failed?

attached mail follows:

Hi Dave,

Wednesday, May 30, 2007, 12:20:48 PM, you wrote:

> If there is no need to return a value then I don't do so. However, the
> function is going to process something, and surely you should check that the
> processing has succeeded or failed?

I have exception and error handling dealt with fully in my functions,
by which stage the 'return' at the end becomes redundant because the
return value doesn't need checking as the error handler has already
taken over. However take the following:

$result = $this->calculateSomething($value);

If 'calculateSomething' has all the error handling it requires built
into it, then isn't checking the value of 'result' superfluous to
requirements? Yet even so, I still like to return something at the end
regardless :)

I guess another way to phrase the same question would be where do you
shift all of your error handling - inside the function itself, or in
the code that calls it (i.e. checking the $result in the example
above). Personally I handle it all in the function otherwise I'm
duplicating masses of result checking.

It isn't a case of wrong/right, just trying to gauge preferences here.

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

attached mail follows:

On Wed, 2007-05-30 at 12:20 +0100, Dave Goodchild wrote:
> If there is no need to return a value then I don't do so. However, the
> function is going to process something, and surely you should check that the
> processing has succeeded or failed?

If you unit test, then returns become quite important, so I almost
always return;

--Paul

All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm

attached mail follows:

2007. 05. 30, szerda keltezéssel 11.52-kor Richard Davey ezt írta:
> Hi all,
>
> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)

personally I prefer to use return only if I need the return value for
something. If it's not used then I think it's just a waste of code lines
and resources to return anything...

greets
Zoltán Németh

>
> Cheers,
>
> Rich
> --
> Zend Certified Engineer
> http://www.corephp.co.uk
>
> "Never trust a computer you can't throw out of a window"
>

attached mail follows:

> If there is no need to return a value then I don't do
> so. However, the function is going to process something,
> and surely you should check that the processing has
> succeeded or failed?

This is precisely the point I was going to make. Unless an argument is
passed in by reference for manipulation within the function, I can't
think of a reason why you wouldn't want to return a value; true or false
at the very least. You call a function to perform, well, a function. I
would think that you would want to know whether or not the process
within the function was successful, yes?

thnx,
Chris

attached mail follows:

Hi Chris,

Wednesday, May 30, 2007, 1:17:39 PM, you wrote:

>> If there is no need to return a value then I don't do
>> so. However, the function is going to process something,
>> and surely you should check that the processing has
>> succeeded or failed?

> This is precisely the point I was going to make. Unless an argument is
> passed in by reference for manipulation within the function, I can't
> think of a reason why you wouldn't want to return a value; true or false
> at the very least. You call a function to perform, well, a function. I
> would think that you would want to know whether or not the process
> within the function was successful, yes?

Even the most simple function can have more than one failure point
within it. If you aren't handling the errors yourself within the
function, you're returning false all over the place and then having to
do the same checking from whatever called it - duplicated however many
times you call that function from your code.

It's a hideous example, but it's straight out of the PHP manual, so
run with it and indulge me:

$mysqli = new mysqli("localhost", "my_user", "my_password", "world");

/* check connection */
if (mysqli_connect_errno()) {
    printf("Connect failed: %s\n", mysqli_connect_error());
    exit();
}

If that was wrapped in a function, sticking 'return false' within the
connect_error check is useful why exactly? Equally the fact the
function didn't 'exit' implies it 'returned true' anyway, so why check
it again in whatever called the function in the first place? it has
performed its task, it didn't raise an error.

(I know most of us would never use 'exit' in production code like the
above, so replace it with whatever error handling mechanism you have,
the question above remains the same.)

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

attached mail follows:

Chris Boget wrote:
>> If there is no need to return a value then I don't do
>> so. However, the function is going to process something,
>> and surely you should check that the processing has
>> succeeded or failed?
>
> This is precisely the point I was going to make. Unless an argument is
> passed in by reference for manipulation within the function, I can't
> think of a reason why you wouldn't want to return a value; true or false
> at the very least. You call a function to perform, well, a function. I
> would think that you would want to know whether or not the process
> within the function was successful, yes?
>
> thnx,
> Chris

All depends on the function.

function someFunc(){
        $this->counter++;
        if($this->counter > 100) $this->counter = 0;
}

Something that simple wont need a return at all.

attached mail follows:

[snip]
All depends on the function.

function someFunc(){
        $this->counter++;
        if($this->counter > 100) $this->counter = 0;
}

Something that simple wont need a return at all.
[/snip]

Classically this would need a return, because $this->counter is going to
be less than 100 most of the time, and you may want to return the value
at some point.

Here is the thing (it is akin to all of the holy wars on brackets, etc),
the use of return has been pounded into old-schoolers heads for a long
time, regardless of the Boolean or value returned. It is good style and
it introduces consistency. As far as it being an extra line of code? So
be it! We're not in the day and age where we had to count CPU cycles! If
anyone is designing PHP applications with that level of granularity they
have entered into an amazingly pedantic process for which PHP is not
well suited.

attached mail follows:

On Wed, May 30, 2007 5:52 am, Richard Davey wrote:
> Just a quick straw-poll really:
>
> What is your take on using 'return' when you end a function, if you
> don't actually need to return a value?
>
> If you have to return say a true/false as the result of an operation,
> then it's an obvious choice. But what if all the function does is
> perform an action and then quit? Do you like to use 'return' at the
> end of it anyway, or do you just let it run into the closing } ?
>
> Or do you perhaps do a 'return true' at the end, regardless, even if
> the rest of your code never checks that value (on the basis that it
> may do in the future)

Planning for a return value that you might need but have no idea what
it will be is probably a Bad Idea -- You'll just need to document it,
maintain it, etc for no real reason.

If the function is only called for side-effects (I.e., it returns
nothing) then don't return anything -- You'll know by looking at the
end of the function that it's not supposed to return anything.

Adding the gratuitous 'return' seems of dubious benefit.

I rarely write a function that doesn't return anything, come to think
of it...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

At 5/30/2007 05:41 AM, Richard Davey wrote:
>/* check connection */
>if (mysqli_connect_errno()) {
> printf("Connect failed: %s\n", mysqli_connect_error());
> exit();
>}
>
>If that was wrapped in a function, sticking 'return false' within the
>connect_error check is useful why exactly? Equally the fact the
>function didn't 'exit' implies it 'returned true' anyway, so why check
>it again in whatever called the function in the first place? it has
>performed its task, it didn't raise an error.
>
>(I know most of us would never use 'exit' in production code like the
>above, so replace it with whatever error handling mechanism you have,
>the question above remains the same.)

I demur at your final point: If we don't use exit() and the function
performs non-aborting error handling, it's going to return to the
calling function which in most cases will need to know whether its
child function succeeded or failed.

In most of the applications I write, an SQL error (not merely an
empty result set) indicates more often than not that the parent code
should gracefully withdraw from the process it was attempting to
perform. SQL errors are going to indicate a syntactical error in the
query, a missing table or field, a connection failure, or another
problem serious enough that the developer's attention should be drawn
to it. It's certainly possible in a thoughtfully-written application
for a parent function not to care whether a child SQL query was
successful on this fundamental level, but in most apps we'll want to know.

         function parent()
         {
                 lookUpData();
                 displayData();
         }
         function lookUpData()
         {
                 set up query;
                 execute query;
                 handle errors;
         }

where "handle errors" might range from returning a failure flag to
displaying an error message.

In order that displayData() doesn't fall on its face, I would write
the parent function in one of these ways:

         if (lookUpData()) displayData();

in which lookUpData() returns true or false, the record set being
passed in a global variable (ugh);

or, if displayData() is smart enough to deal intelligently with a
null or empty result set:

         $aResultSet = lookUpData();
         displayData($aResultSet);
or:
         displayData(lookUpData());

in which lookUpData() returns a dataset array that's empty if no
records were found or an error was encountered.

In my programming style, I can't imagine wanting to write this code
in such a way that lookUpData() didn't return some form of success or
error indicator.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

attached mail follows:

>
> Even the most simple function can have more than one failure point
> within it. If you aren't handling the errors yourself within the
> function, you're returning false all over the place and then having to
> do the same checking from whatever called it - duplicated however many
> times you call that function from your code.
>

I don't know if arbitrarily inserting a return true|false onto the end of a
function is going to make it future-proof; what if that changes from a
true|false to a 0|1, or you want/need to return null? Will you break all the
distributed procedural checks peppered all over the script? I posit, if
you're not experienced/bright enough to consider these factors when coding,
you will probably make a mistake anyways.

Code to what you need (be it functional, OO, whatever), but have high
standards... :D

I think putting "return;" at the end of every function is probably a healthy
practice, but is it best practice? If it's poorly written and/or poorly
factored code, it doesn't make any difference if they have returns on
everything, it's still junky code.

But I don't believe "return true/false" is a good practice, especially for
those who WOULD NOT normally use it due to inexperience. Putting an
artificial return value that is arbitrary isn't really all that useful, and
might in the future cause headaches (see above).

Do you put returns on __construct() and __destruct()? They are functions,
too.

And there are times when a true/false response is meaningless. For instance,
if you have a public value settor but you don't want the value to be seen
publicly, do you want to return it? Well, no. Would a boolean be useful?
Maybe, if you can regex against a pattern or something, or check for a null
or empty value.

Should those checks be contained in the codeblock or class BEFORE returning?
I think so. In OOP (less in functional/procedural), I would make a
checkState() or isValueSet() or isUsable() method that returns boolean if
necessary (for example, a dependant object check), or push the logic into a
class creation and check type on function call. I think this also makes the
code easier to understand and puts logic in it's place by type (functions,
methods, members, checks). You can also pool checks together to validate an
object member, meaning code reuse is in effect. Exceptions come in handy.

YMMV

But, y'know, I'm sure there are cases where this could be proven wrong, but
personally, I see them as edge-cases mostly, that must be known when the
code is written. Again, by paying close attention and refactoring (and
hopefully unit testing), this is a moot question anyways. PHP's soft-typing
complicates this further (0 == false == null == '' == ??????). This makes a
whole lot more sense in C++ or something other strong-typed language.

Thus, code to what you need, but have high standards (by knowing what you
need)!

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

attached mail follows:

Hi Paul,

Wednesday, May 30, 2007, 4:07:00 PM, you wrote:

> I demur at your final point: If we don't use exit() and the function
> performs non-aborting error handling, it's going to return to the
> calling function which in most cases will need to know whether its
> child function succeeded or failed.

> function parent()
> {
> lookUpData();
> displayData();
> }
> function lookUpData()
> {
> set up query;
> execute query;
> handle errors;
> }

> where "handle errors" might range from returning a failure flag to
> displaying an error message.

There's a world of difference between those two events though. If all
'handle errors' does is to return an error flag, then the parent
obviously *needs* to check it. Equally all other functions that ever
call lookUpData() need to duplicate those checks too.

> In order that displayData() doesn't fall on its face, I would write
> the parent function in one of these ways:

> if (lookUpData()) displayData();

That's where our approach differs. If lookUpData falls flat on its
face, my error handler will take over completely, finally resulting in
an 'abortive' event, and never pass back to the parent. If an error is
of a critical enough nature the system needs to stop. If it's not
critical then the error handling within displayData() would detect it
has nothing to display and error in its own accord.

> In my programming style, I can't imagine wanting to write this code
> in such a way that lookUpData() didn't return some form of success or
> error indicator.

That's a *very* specific example though. My question was do people
place a 'return' statement at the end of **ALL** of their functions,
regardless of what that function actually did. In the code you gave
there is a fair argument both ways, but that isn't always the case.

Here's a piss-poor example off the top of my head:

function parent()
{
         display()
}

function display()
{
         echo something random
}

In this instance (albeit gloriously simple / useless), would your
display() return true even though it could have never actually failed?
and if it did, do you then care about checking that value in the
parent?

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

attached mail follows:

Hi Jared,

Wednesday, May 30, 2007, 4:10:45 PM, you wrote:

[snip]
> I think putting "return;" at the end of every function is probably a healthy
> practice, but is it best practice? If it's poorly written and/or poorly
> factored code, it doesn't make any difference if they have returns on
> everything, it's still junky code.

If you do put a return; at the end of all of your functions, I'm
curious as to why? If a function doesn't actually return a value
(which is highly possible) then it isn't /required/, but that doesn't
stop me from doing it. I *do* put 'return;' at the end of all
functions (my question to the list was - does anyone else?)

That is all my original thread was ever really asking - I was just
curious what other people thought about returning from functions that
don't actually require a return value. So far the responses have been
pretty varied, from the (somewhat blinkered) 'how can a function never
return something?', to 'yes I always return' to 'no I just let it run
out'.

Based on the variety of replies it appears there is no 'standard' for
this. Just as with code structure and studly-caps it's obviously a bit
of a religious debate.

I think perhaps it is a psychological thing actually, as if I don't
consider the function 'finished' until it hits a return;. Almost like
you're issuing an instruction to tell PHP "yes, as the programmer I am
now happy for you to return to where-ever you were called from" -
perhaps just a way of exerting our control :)

> Should those checks be contained in the codeblock or class BEFORE returning?
> I think so.

I would agree (because it's how I do it ;), but this isn't an approach
everyone takes.

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

attached mail follows:

> Hi Jared,

Hi Rich!

> If you do put a return; at the end of all of your functions, I'm
> curious as to why? If a function doesn't actually return a value
> (which is highly possible) then it isn't /required/, but that doesn't
> stop me from doing it. I *do* put 'return;' at the end of all
> functions (my question to the list was - does anyone else?)

I went through a phase where I *did* make a point to put returns on all
functions and class methods. This helped for a little while, as it caused me
to slow down a little and think about my code (why is why I think it could
be a healthy practice, especially for someone who is less experienced).

Now, I don't worry at all about it all (meaningless returns, that is). The
way I do things supercedes in a lot of cases worrying about returning
values, and since I have many more experiences, I don't worry about it. When
putting together some code, having meaningless "return;"s inserted at the
end of every code block seems more wasteful than helpful in most cases, so I
don't by practice append returns when unnecessary, although at times I have
done it.

It really doesn't matter in PHP (AFAIK), it all has to do with coding
patterns and practice, and what and how that is impacted by appending
returns. Is it helpful to always stop and think about a return value? Sure!
If you've been coding for five years and you are now equipped with advanced
methods and factoring iterations that render it moot? Personal preference
and dogma I assume will rule the day here.

> That is all my original thread was ever really asking - I was just
> curious what other people thought about returning from functions that
> don't actually require a return value. So far the responses have been
> pretty varied, from the (somewhat blinkered) 'how can a function never
> return something?', to 'yes I always return' to 'no I just let it run
> out'.

Maybe someone can shed light on what happens when the parser encounters a
"return;". Would there be anything useful to that (I don't think so, but I
don't know).

> Based on the variety of replies it appears there is no 'standard' for
> this. Just as with code structure and studly-caps it's obviously a bit
> of a religious debate.

If bumpy/camel case zealots are the bedouins of programming, what are people
who insist on returns? Returnaholics?

> I think perhaps it is a psychological thing actually, as if I don't
> consider the function 'finished' until it hits a return;. Almost like
> you're issuing an instruction to tell PHP "yes, as the programmer I am
> now happy for you to return to where-ever you were called from" -
> perhaps just a way of exerting our control :)

It can also be used to visually parse a page of code ("returns at this tab
spacing means end of code block..."). So it can make the code modestly
easier to read, maybe.

And no, I don't think programmers are ever control freaks. Ever. No, I said
EVER. You're wrong.

> > Should those checks be contained in the codeblock or class BEFORE
returning?
> > I think so.
>
> I would agree (because it's how I do it ;), but this isn't an approach
> everyone takes.

There are times when "return;" is meaningful, such as breaking out of loops
(and the function), switch statements, and whatnot. For all other times when
a return isn't expressly meaningful, I see it as a matter personal
preference, which is usually influenced by someone else's overarching
dogmatic philosophy being impressed on them.

Good thing there aren't folks like that in programming! Right?!?

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

attached mail follows:

At 5/30/2007 08:25 AM, Richard Davey wrote:
> > In order that displayData() doesn't fall on its face, I would write
> > the parent function in one of these ways:
>
> > if (lookUpData()) displayData();
>
>That's where our approach differs. If lookUpData falls flat on its
>face, my error handler will take over completely, finally resulting in
>an 'abortive' event, and never pass back to the parent. If an error is
>of a critical enough nature the system needs to stop. If it's not
>critical then the error handling within displayData() would detect it
>has nothing to display and error in its own accord.

Hi Richard,

If you write your applications like this then they'll fall over when
something goes wrong -- and here I mean 'fall over' to mean aborting
suddenly with a technical error message. That can be useful to us
during development & debugging but isn't really useful or friendly to
the website visitor.

It also gives every subroutine that handles errors the responsibility
of deciding how to deal with the error -- whether to display it or
not, how to display it, etc. It makes code less portable from one
application to the next.

Consider another model in which subroutines report errors back to the
calling code but don't themselves 'act' on the errors. An error on a
low level can bubble back up to some higher parent level in the
application that knows what to do: whether to display and if so how
and in what human language, whether to email the developer, whether
to close down the application or continue, etc. An English SQL error
message is of little use to a web page in Japanese. It's usually a
mistake to display an SQL query in a public application because it
exposes sensitive details of the database architecture.

For example, we might want to generate the web page even if some part
of its content is unavailable due to the SQL error. This leaves the
visitor with a functional page from which they can navigate normally
even if part of the content is missing. On this high level, the
application might choose to behave nonchalantly as though SQL had
returned an empty recordset and report the hard error to the
webmaster behind the scenes.

This kind of error-handling architecture can be handled in a variety
of ways. One is to maintain a global error structure or class with a
variety of fields that relate to the last error: true/false, error
type, context, query code if applicable, etc. Because a low-level
error may in turn trigger higher-level errors as it bubbles back up,
it may make sense to turn this into an error stack to which each
calling function adds its understanding of the problem as the error
bubbles back up:

         0: SQL error ZZZ in "SELECT * FROM `users` ..."
         1: Can't query user list YYY
         2: No users to display

When a high-level function receives an error state from a called
function, it can (if desired) walk down the stack to learn the
technical origin of the error as well as its implications during the bubble-up.

> > In my programming style, I can't imagine wanting to write this code
> > in such a way that lookUpData() didn't return some form of success or
> > error indicator.
>
>That's a *very* specific example though. My question was do people
>place a 'return' statement at the end of **ALL** of their functions,
>regardless of what that function actually did. In the code you gave
>there is a fair argument both ways, but that isn't always the case.

Absolutely. I agree with most of the respondents to this thread:
return a value only if the caller needs to receive a value
back. Some languages (such as BASIC) distinguish between functions
that return values and subroutines that don't. Because PHP gives
only one type of function to call, with an option whether or not to
return anything, it's clearly up to us to design and impose that
architecture based on our knowledge and preferences.

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

attached mail follows:

On Wed, May 30, 2007 7:42 am, Darren Whitlen wrote:
> Chris Boget wrote:
>>> If there is no need to return a value then I don't do
>>> so. However, the function is going to process something,
>>> and surely you should check that the processing has
>>> succeeded or failed?
>>
>> This is precisely the point I was going to make. Unless an argument
>> is
>> passed in by reference for manipulation within the function, I can't
>> think of a reason why you wouldn't want to return a value; true or
>> false
>> at the very least. You call a function to perform, well, a
>> function. I
>> would think that you would want to know whether or not the process
>> within the function was successful, yes?

I guess if you're using lots of OOP and try/catch/throw, you'd end up
very rarely having a function return a pass/fail value...

Just depends on coding style, I guess.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

----- Original Message -----
From: "Richard Davey" <richcorephp.co.uk>
> That is all my original thread was ever really asking - I was just
> curious what other people thought about returning from functions that
> don't actually require a return value. So far the responses have been
> pretty varied, from the (somewhat blinkered) 'how can a function never
> return something?', to 'yes I always return' to 'no I just let it run
> out'.
>

My rule is to write what you mean, and if you don't mean to return anything
valid or worth anything, just don't. If you explicitly put a return it
should be for a reason, whatever you return should be meaningful. If I find
a 'return true' at the end of a piece of code, I will check if there is any
condition where it returns false, because I will assume that the return true
is significant and so should be its obvious alternative. I would also
wonder why the caller doesn't use that return value or if it does, why is
there no 'else' part.

In a similar line, I use 'null' in databases when I mean 'I have no valid
information for this field'. Basically, the idea is to be clear in what you
mean. If you put a return it should be because you mean to return
something. If you mean you don't know, use 'null', don't default to zero or
any other implausible value for that field. This kind of arbitrary
conventions dilute the self-documenting value of well-written code, quite
the opposite, they would need to be documented themselves to avoid
missinterpretations.

Satyam

attached mail follows:

> My rule is to write what you mean, and if you don't mean to return
anything
> valid or worth anything, just don't. If you explicitly put a return it
> should be for a reason, whatever you return should be meaningful. If I
find
> a 'return true' at the end of a piece of code, I will check if there is
any
> condition where it returns false, because I will assume that the return
true
> is significant and so should be its obvious alternative. I would also
> wonder why the caller doesn't use that return value or if it does, why is
> there no 'else' part.
>
> In a similar line, I use 'null' in databases when I mean 'I have no valid
> information for this field'. Basically, the idea is to be clear in what
you
> mean. If you put a return it should be because you mean to return
> something. If you mean you don't know, use 'null', don't default to zero
or
> any other implausible value for that field. This kind of arbitrary
> conventions dilute the self-documenting value of well-written code, quite
> the opposite, they would need to be documented themselves to avoid
> missinterpretations.
>
> Satyam

Great point! If you put an arbitrary value in (and yeah, people will put
return true if they don't know any better), will this make the code even
more confusing? "return;" of course, is different (and only meaningful if
used to break a function).

Does the parser insert a "return;" for you, like the parser puts a ?> on the
end of a PHP script that doesn't have it (I heard it does, anyways; I, of
course, ALWAYS...).

Additionally, does anyone know if "return;" to close a code block out that
is exhausted (at the final "}") was ever meaningful, such as in other
languages?

I think in a lot of cases using surrogates is a better, scalable solution,
but that only matters if you need a "better, scalable solution." Depends on
coding style, preference, and the situational need.

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

attached mail follows:

On Wed, May 30, 2007 10:25 am, Richard Davey wrote:
> Hi Paul,
>
> Wednesday, May 30, 2007, 4:07:00 PM, you wrote:
>
>> I demur at your final point: If we don't use exit() and the
>> function
>> performs non-aborting error handling, it's going to return to the
>> calling function which in most cases will need to know whether its
>> child function succeeded or failed.
>
>> function parent()
>> {
>> lookUpData();
>> displayData();
>> }
>> function lookUpData()
>> {
>> set up query;
>> execute query;
>> handle errors;
>> }
>
>> where "handle errors" might range from returning a failure flag to
>> displaying an error message.
>
> There's a world of difference between those two events though. If all
> 'handle errors' does is to return an error flag, then the parent
> obviously *needs* to check it. Equally all other functions that ever
> call lookUpData() need to duplicate those checks too.
>
>> In order that displayData() doesn't fall on its face, I would write
>> the parent function in one of these ways:
>
>> if (lookUpData()) displayData();
>
> That's where our approach differs. If lookUpData falls flat on its
> face, my error handler will take over completely, finally resulting in
> an 'abortive' event, and never pass back to the parent. If an error is
> of a critical enough nature the system needs to stop. If it's not
> critical then the error handling within displayData() would detect it
> has nothing to display and error in its own accord.

This sounds perfectly reasoanble.

>> In my programming style, I can't imagine wanting to write this code
>> in such a way that lookUpData() didn't return some form of success
>> or
>> error indicator.
>
> That's a *very* specific example though. My question was do people
> place a 'return' statement at the end of **ALL** of their functions,
> regardless of what that function actually did. In the code you gave
> there is a fair argument both ways, but that isn't always the case.
>
> Here's a piss-poor example off the top of my head:
>
> function parent()
> {
> display()
> }
>
> function display()
> {
> echo something random
> }
>
> In this instance (albeit gloriously simple / useless), would your
> display() return true even though it could have never actually failed?
> and if it did, do you then care about checking that value in the
> parent?

Technically, there is no such thing as "could have never actually
failed"...

It's not outside the realm of possibility that:
echo "something random";
could actually fail...

In all the ways I can think of, PHP would never actually return, but
there's no guarantee that won't change under the hood tomorrow...

I'm not saying that every scripter should worry about this; but if you
have a mission-critical application in PHP, you should probably go
ahead and return true/false on success/failure of every function, no
matter how trivial it may seem.

But for your basic website, no, you don't need that level of
robustness -- The Internet itself will cause so many failures that
your lack of error-checking for something that rare will be lost as
"noise" in any sort of statistical error model.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

On Wed, May 30, 2007 12:00 pm, Paul Novitski wrote:
[snip] use the archives

I think there is a LOT of value in bubbling up errors to the
appropriate level of handling, and letting the right layer do the
right job for the error.

HOWEVER: it is not a good idea, imho, to "always" let the errors
bubble up to the outer layer, which is what Paul seemed to have
typed...

The problem with that approach is that you end up being painted into a
corner where your application can do little more than print "It
broke." because the low-level context is not available to the caller
of the function.

The lowest layers of your application should be logging very precise
info about the error for the developer, with code for every possible
error condition you can think of, and hopefully defaults for error
conditions you can't think of.

The middle layers might return a smaller set of common error
codes/messages.

The outer layer might lookup error codes to print suitable end-user
messages, or translate with gettext or...

In an ideal world, the outer layer presents the end user with
something meaningful to them, while providing an error code or unique
identifier that a developer can use to locate the detailed info needed
to fix the problem.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

On Wed, May 30, 2007 7:56 am, Jay Blanchard wrote:
> Classically this would need a return, because $this->counter is going
> to
> be less than 100 most of the time, and you may want to return the
> value
> at some point.

Or you may not ever need to return it.

And if you return it for no reason, you have to document what the
function returns, maintain it as returning that, and can never decide
to return something else more useful tomorrow, when you find out what
you actually need to return.

> Here is the thing (it is akin to all of the holy wars on brackets,
> etc),
> the use of return has been pounded into old-schoolers heads for a long
> time, regardless of the Boolean or value returned. It is good style
> and
> it introduces consistency. As far as it being an extra line of code?
> So
> be it! We're not in the day and age where we had to count CPU cycles!
> If
> anyone is designing PHP applications with that level of granularity
> they
> have entered into an amazingly pedantic process for which PHP is not
> well suited.

As I recall, the reasons for always returning something in C are
pretty irrelevant to PHP...

I think there was a time when (void) was not a valid return data type,
so you HAD to return at least an (int) -- and programmers would start
to rely on the essentially random value being returned always being 0
when it wasn't going to always be 0 -- it just happened to always be 0
due to that was what was always in the byte on the stack... Until you
changed your code and the whole thing went to the toilet because of
the assumption about what was being returned.

PHP and C have many similarities, but that doesn't mean that every
Best Practice is going to transfer over, because they are very very
different languages.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

At 5/30/2007 10:51 AM, Richard Lynch wrote:
>On Wed, May 30, 2007 12:00 pm, Paul Novitski wrote:
>[snip] use the archives

Good suggestion!

>HOWEVER: it is not a good idea, imho, to "always" let the errors
>bubble up to the outer layer, which is what Paul seemed to have
>typed...

But didn't.

>The problem with that approach is that you end up being painted into a
>corner where your application can do little more than print "It
>broke." because the low-level context is not available to the caller
>of the function.

If you'll refer back to my posting to which you're replying without
quoting, you'll read:

At 5/30/2007 10:00 AM, Paul Novitski wrote:
>Because a low-level error may in turn trigger higher-level errors as
>it bubbles back up, it may make sense to turn this into an error
>stack to which each calling function adds its understanding of the
>problem as the error bubbles back up:
...
>When a high-level function receives an error state from a called
>function, it can (if desired) walk down the stack to learn the
>technical origin of the error as well as its implications during the bubble-up.

It sounds like we're on the same page, Richard!

Regards,

Paul
__________________________

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com

attached mail follows:

On Wed, 2007-05-30 at 17:24 +0100, Richard Davey wrote:
> Hi Jared,
>
> Wednesday, May 30, 2007, 4:10:45 PM, you wrote:
>
> [snip]
> > I think putting "return;" at the end of every function is probably a healthy
> > practice, but is it best practice? If it's poorly written and/or poorly
> > factored code, it doesn't make any difference if they have returns on
> > everything, it's still junky code.
>
> If you do put a return; at the end of all of your functions, I'm
> curious as to why? If a function doesn't actually return a value
> (which is highly possible) then it isn't /required/, but that doesn't
> stop me from doing it. I *do* put 'return;' at the end of all
> functions (my question to the list was - does anyone else?)

If there's no reason for it to return something, why bother? It's like
telling the reader of your code that they're a complete and utter moron
because obviously you need to point out explicitly that the code returns
at that point because they obviously couldn't infer it from having
reached the end of the function :)

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. |
`------------------------------------------------------------'

attached mail follows:

On May 30, 2007, at 6:32 AM, Richard Davey wrote:

> Hi Dave,
>
> Wednesday, May 30, 2007, 12:20:48 PM, you wrote:
>
>> If there is no need to return a value then I don't do so. However,
>> the
>> function is going to process something, and surely you should
>> check that the
>> processing has succeeded or failed?
>
> I have exception and error handling dealt with fully in my functions,
> by which stage the 'return' at the end becomes redundant because the
> return value doesn't need checking as the error handler has already
> taken over. However take the following:
>
> $result = $this->calculateSomething($value);
>
> If 'calculateSomething' has all the error handling it requires built
> into it, then isn't checking the value of 'result' superfluous to
> requirements? Yet even so, I still like to return something at the end
> regardless :)

I normally (but not always) return (whether I will actually use that
value or not).

> I guess another way to phrase the same question would be where do you
> shift all of your error handling - inside the function itself, or in
> the code that calls it (i.e. checking the $result in the example
> above). Personally I handle it all in the function otherwise I'm
> duplicating masses of result checking.

I spent some time thinking about this exact question and I came up
with several things:

1. How does PHP do it?

They have a function which performs whatever and returns an error
(code) upon failing. This allows every developer to deal with the
error in their own way.

2. Does this function need to be portable? (Short answer, yes, it
*should* be.)

Take these functions for example:

<?
function doSomethingToA ($a)
{
    if (!$a) $_SESSION["not_portable"] = false;
    else $_SESSION["not_portable"] = true;
    return; // optional
}

function doSomethingToB ($b)
{
    if (!$b) return false;
    else return true;
}

// Non-portable function that probably won't work outside this
application
doSomethingToA ($_SESSION["whatever"]);

// Portable function that you can take anywhere! =D
$_SESSION["portable"] = doSomethingToB ($_SESSION["whatever"]);
?>

Yes, you may have to do some more error-checking on the outside of
the function. However, the question comes down to... what's your use
for it. It's almost a religious question - it's up to you on how you
code. Just be sure to weigh all the options.

~Philip

> It isn't a case of wrong/right, just trying to gauge preferences here.
>
> Cheers,
>
> Rich

attached mail follows:

Stut wrote:
> Sebe wrote:
>> Yeni Setiawan wrote:
>>>
>>>
>>> On 5/30/07, *Sebe* <sebastiandslr.net <mailto:sebastiandslr.net>>
>>> wrote:
>>>
>>> I run some scripts via php (cgi) which sends output to another
>>> file, but
>>> it's including unwanted cookie header, etc in the outfile.
>>>
>>> example:
>>>
>>> php /home/dev/script.php > /home/production/feeds/news.xml 2>&1
>>>
>>> and at the top of news.xml i get:
>>>
>>> X-Powered-By: PHP/5.2.2
>>> Set-Cookie: .....
>>> Set-Cookie: .....
>>> Cache-Control: private
>>> Content-Type: text/html; charset=ISO-8859-1
>>>
>>> i turned off expose php which gets rid of the x-powered-by but what
>>> about the rest?
>>>
>>>
>>>
>>>
>>> try to use quiet mode by using -q option as follow:
>>>
>>> php -q /home/dev/script.php > /home/production/feeds/news.xml 2>&1
>>>
>> i tried using -q
>> still shows the headers.. this problem started when i switched to php
>> cgi.
>
> Well that's your mistake. The CGI binary is meant for use as a web
> page generator. You need php-cli.
>
> -Stut

turning cgi.check_shebang_line in php.ini solved the problem without
using php cli

attached mail follows:

On Wed, 2007-05-30 at 09:38 +0100, Stut wrote:
> Sebe wrote:
> >
> > i tried using -q
> > still shows the headers.. this problem started when i switched to php cgi.
>
> Well that's your mistake. The CGI binary is meant for use as a web page
> generator. You need php-cli.

While php-cli is an improvement over php-cgi for shell scripts it is not
a necessity unless you want better handling of stdin and the other
streams. That has been my experience, so much so that I haven't bothered
updating any old scripts that still make use of the php-cgi binary.
They've worked all the way from php 4.1.0 all the way through 5.2.0 (I
haven't bothered with 5.2.1 or 5.2.2 yet :) I do always run them with
the -qC flags though.

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. |
`------------------------------------------------------------'

attached mail follows:

php -q

On Wed, May 30, 2007 1:11 am, Sebe wrote:
> I run some scripts via php (cgi) which sends output to another file,
> but
> it's including unwanted cookie header, etc in the outfile.
>
> example:
>
> php /home/dev/script.php > /home/production/feeds/news.xml 2>&1
>
> and at the top of news.xml i get:
>
> X-Powered-By: PHP/5.2.2
> Set-Cookie: .....
> Set-Cookie: .....
> Cache-Control: private
> Content-Type: text/html; charset=ISO-8859-1
>
> i turned off expose php which gets rid of the x-powered-by but what
> about the rest?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

On Wed, May 30, 2007 2:47 am, Sebe wrote:
> Yeni Setiawan wrote:
>>
>>
>> On 5/30/07, *Sebe* <sebastiandslr.net <mailto:sebastiandslr.net>>
>> wrote:
>>
>> I run some scripts via php (cgi) which sends output to another
>> file, but
>> it's including unwanted cookie header, etc in the outfile.
>>
>> example:
>>
>> php /home/dev/script.php > /home/production/feeds/news.xml 2>&1
>>
>> and at the top of news.xml i get:
>>
>> X-Powered-By: PHP/5.2.2
>> Set-Cookie: .....
>> Set-Cookie: .....
>> Cache-Control: private
>> Content-Type: text/html; charset=ISO-8859-1
>>
>> i turned off expose php which gets rid of the x-powered-by but
>> what
>> about the rest?
>>
>>
>>
>>
>> try to use quiet mode by using -q option as follow:
>>
>> php -q /home/dev/script.php > /home/production/feeds/news.xml 2>&1
>>
> i tried using -q
> still shows the headers.. this problem started when i switched to php
> cgi.

I guess that's why we have both CLI and CGI...

Go back to CLI, not CGI.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

Greetings!

I need to write a script to import '.csv' data files into MySQL.

My question is how can I have a script execute and check a directory
every 4 hours for any '.csv' files and if it finds any calls a function
to import them?

Thanks,

Dave

**********************************************************************
HTC Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
**********************************************************************

attached mail follows:

On a *nix-box it's fairly simple when using cronjobs... maybe try that?

----- Original Message -----
From: "Bosky, Dave" <Dave.Boskyhtcinc.net>
To: <php-generallists.php.net>
Sent: Wednesday, May 30, 2007 2:14 PM
Subject: [PHP] scheduling a script to check a directory for files

Greetings!

I need to write a script to import '.csv' data files into MySQL.

My question is how can I have a script execute and check a directory
every 4 hours for any '.csv' files and if it finds any calls a function
to import them?

Thanks,

Dave

**********************************************************************
HTC Disclaimer: The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer. Thank you.
**********************************************************************

attached mail follows:

> I need to write a script to import '.csv' data files into MySQL.
>
> My question is how can I have a script execute and check a directory
> every 4 hours for any '.csv' files and if it finds any calls a function
> to import them?

On linux there is cron (you should find many example by googling) on
windows there is the task scheduler...
And then finally you can use PHPs delay func and a loop ;)

The any part can be done by globbing, DirectoryIterator, shell scripts
..

Marc

attached mail follows:

On Wed, May 30, 2007 7:14 am, Bosky, Dave wrote:
> I need to write a script to import '.csv' data files into MySQL.
>
> My question is how can I have a script execute and check a directory
> every 4 hours for any '.csv' files and if it finds any calls a
> function
> to import them?

Linux: man 5 crontab
* */4 * * * /usr/local/bin/php -q import.php

Windows: Scheduled Tasks
[interminible dialogs here]

-------- import.php --------
<?php
  //Untested code
  //Needs better error handling
  //Will not scale well to *large* .csv files...
  //Use mysql LOAD DATA IN FILE for large csv files
  $path = '/path/to/directory';
  $dir = opendir($path) or die("Failed to open '$path'");
  while (($file = readdir($dir)) !== false){
    if ($file == '.' || $file == '..') continue;
    if (!preg_match('|.csv$|i', $file)){
      echo "What's '$file' doing in the .csv import directory?\n";
      continue;
    }
    $f = fopen("$path/$file", 'r');
    if (!$f){
      echo "Failed to open '$path/$file'\n";
      continue;
    }
    while (!feof($f)){
      $row = fgetcsv($f, 1000000);
      array_map('mysql_real_escape_string', $row);
      $row_sql = implode("', '", $row);
      $query = "insert into whatever values ('$row_sql')";
      mysql_query($query) or die(mysql_error());
    }
  }
?>

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

> On linux

Our webmaster actually sets up a cron to call a Lynx browser that navigates
to the page. How he did this, I'm not sure (me windows, linux NO!), but at
the time, cron didn't cut it (for some reason), where Lynx worked perfectly.
Probably had something to do with not using CLI to handle the call, though.

http://en.wikipedia.org/wiki/Lynx_(web_browser)

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

attached mail follows:

I have tried to share my experience over a problem related to sessions but was unable to submit as the SPAM question is really very confusing. So I am just submitting it here:-

Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0

If that iritating warning occurs then check the mistyped PHP variables assigned to session variable.
I faced the same problem and half an hour after getting on my nerves I found the typing mistake and the infamous warning disappeared.
As there aren't many articles when I googled, I thought this might be help someone..

Regards,
Sachin Mahajan
(essem76yahoo.com)

attached mail follows:

Dear all

We need to develop a system where we can upload really big files. IE 15
- 25 Mb.
So I know you can set the limit of the upload thats not a problem, I
know a problem that we might experience is that the browser might time
out. Is there any way around this? and also are there other problems I
might encounter?

Thanks in advance

angelo
--
------------------------------------------------------------------------
Angelo Zanetti
Systems developer
------------------------------------------------------------------------

*Telephone:* +27 (021) 469 1052
*Mobile:* +27 (0) 72 441 3355
*Fax:* +27 (0) 86 681 5885
*
Web:* http://www.zlogic.co.za
*E-Mail:* angelozlogic.co.za <mailto:angelozlogic.co.za>

attached mail follows:

On 5/30/07, Angelo Zanetti <angelozlogic.co.za> wrote:
> Dear all
>
> We need to develop a system where we can upload really big files. IE 15
> - 25 Mb.
> So I know you can set the limit of the upload thats not a problem, I
> know a problem that we might experience is that the browser might time
> out. Is there any way around this? and also are there other problems I
> might encounter?
>
> Thanks in advance
>
> angelo

I wouldn't recommend uploading big files through the browser, as the
HTTP protocol isn't designed for that. FTP is designed for that, and
if you can, use it :)

I have uploaded really big files with my browser, which sometimes take
several days to complete, and didn't time out, so I don't think it
will be a problem with relative new browsers. (I did with IE6, later
with FireFox on linux)

But, it's very annoying when you're at 90% of upload and your Internet
connection hangs for a few seconds, as that would kill the upload
process and you need to start over again.
If you have a lot of uploads at the same time, it might get your
system out of resources, as all uploads are stored in the RAM while
the user is uploading. So, if you have 100 people uploading, and they
all have already uploaded 10 MB of their file, you would have 1000MB
allocated. In contrast with FTP, as FTP will store the uploads
directly to the drive.

Tijnema

attached mail follows:

2007. 05. 30, szerda keltezéssel 15.47-kor Angelo Zanetti ezt írta:
> Dear all
>
> We need to develop a system where we can upload really big files. IE 15
> - 25 Mb.
> So I know you can set the limit of the upload thats not a problem, I
> know a problem that we might experience is that the browser might time
> out. Is there any way around this? and also are there other problems I
> might encounter?

http://www.php.net/manual/en/ref.info.php#ini.max-execution-time

hope that helps
Zoltán Németh

>
> Thanks in advance
>
> angelo
> --
> ------------------------------------------------------------------------
> Angelo Zanetti
> Systems developer
> ------------------------------------------------------------------------
>
> *Telephone:* +27 (021) 469 1052
> *Mobile:* +27 (0) 72 441 3355
> *Fax:* +27 (0) 86 681 5885
> *
> Web:* http://www.zlogic.co.za
> *E-Mail:* angelozlogic.co.za <mailto:angelozlogic.co.za>
>

attached mail follows:

On Wed, May 30, 2007 8:47 am, Angelo Zanetti wrote:
> We need to develop a system where we can upload really big files. IE
> 15
> - 25 Mb.

You're pushing the limit on user patience and browser timeouts...

> So I know you can set the limit of the upload thats not a problem, I
> know a problem that we might experience is that the browser might time
> out. Is there any way around this?

Nope.

The browser gets tired of waiting around for the upload to complete
because your server is too slow/busy, and the user has a very bad
experience.

file upload was grafted onto HTTP rather late in the game, and shows
the scars badly.

> and also are there other problems I
> might encounter?

Woof.

Yes, there are many problems you might encounter :-)

Users on slow/flaky connectionns will never have a good experience
with HTTP file upload. Give them FTP or SCP or something that is more
stable and will re-try.

You also have to consider what users might choose to upload that is
not what you wanted. There are all kinds of people out there looking
to upload "interesting" content that you don't actually want, most
likely.

There is a Flikr book out there that might have some insight for you.
They obviously dealt with this already, and wrote a whole book all
about Flikr, so it's probably got something in there covering this.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

Hi,

Maybe quite strange question and quite off topic, but there's PHP involved :)

I want to read out files, and then I come across 4byte DWORD values,
they are stored in little endian values, but how do I get in a PHP
string (as the values are too large for integer)

My code is currently this:
$data = fread($fp,4);
$value = (ord(substr($data,3,1))*256*256*256)+(ord(substr($data,2,1))*256*256)+(ord(substr($data,1,1))*256)+(ord(substr($data,0,1)));

and now $value contains the value of the DWORD, it works fine, but it
seems that it could be done a lot easier :)
Anyone experience with it?

Tijnema

attached mail follows:

> -----Original Message-----
> From: Tijnema [mailto:tijnemagmail.com]
> Sent: 30 May 2007 15:20
> To: php
> Subject: [PHP] Best way to convert Little-Endian DWORD to string
>
>
> Hi,
>
> Maybe quite strange question and quite off topic, but there's PHP
> involved :)
>
> I want to read out files, and then I come across 4byte DWORD values,
> they are stored in little endian values, but how do I get in a PHP
> string (as the values are too large for integer)
>
> My code is currently this:
> $data = fread($fp,4);
> $value =
> (ord(substr($data,3,1))*256*256*256)+(ord(substr($data,2,1))*256*2
> 56)+(ord(substr($data,1,1))*256)+(ord(substr($data,0,1)));
>
> and now $value contains the value of the DWORD, it works fine, but it
> seems that it could be done a lot easier :)
> Anyone experience with it?

Could you not use the << bitwise operator?

Edward

attached mail follows:

On 5/30/07, Edward Kay <edwardlabhut.com> wrote:
>
>
> > -----Original Message-----
> > From: Tijnema [mailto:tijnemagmail.com]
> > Sent: 30 May 2007 15:20
> > To: php
> > Subject: [PHP] Best way to convert Little-Endian DWORD to string
> >
> >
> > Hi,
> >
> > Maybe quite strange question and quite off topic, but there's PHP
> > involved :)
> >
> > I want to read out files, and then I come across 4byte DWORD values,
> > they are stored in little endian values, but how do I get in a PHP
> > string (as the values are too large for integer)
> >
> > My code is currently this:
> > $data = fread($fp,4);
> > $value =
> > (ord(substr($data,3,1))*256*256*256)+(ord(substr($data,2,1))*256*2
> > 56)+(ord(substr($data,1,1))*256)+(ord(substr($data,0,1)));
> >
> > and now $value contains the value of the DWORD, it works fine, but it
> > seems that it could be done a lot easier :)
> > Anyone experience with it?
>
> Could you not use the << bitwise operator?
>
> Edward

How could I use them here?
I read the docs for bitwise operators, and they tell me what they do,
but now how to use it :(

Tijnema

attached mail follows:

On Wed, May 30, 2007 9:19 am, Tijnema wrote:
> Maybe quite strange question and quite off topic, but there's PHP
> involved :)
>
> I want to read out files, and then I come across 4byte DWORD values,
> they are stored in little endian values, but how do I get in a PHP
> string (as the values are too large for integer)
>
> My code is currently this:
> $data = fread($fp,4);
> $value =
> (ord(substr($data,3,1))*256*256*256)+(ord(substr($data,2,1))*256*256)+(ord(substr($data,1,1))*256)+(ord(substr($data,0,1)));
>
> and now $value contains the value of the DWORD, it works fine, but it
> seems that it could be done a lot easier :)
> Anyone experience with it?

Easiest might be to read one byte at a time...

$byte0 = fread($fp, 1);
$byte1 = fread($fp, 1);
$byte2 = fread($fp, 1);
$byte3 = fread($fp, 1);
$value = $byte3 * 0xffffff + $byte2 * 0xffff + $byte1 * 0xff + $byte0;

If that makes fread too slow, which it might, but buffering should be
able to handle 4 bytes...

You could also do:
$byte0 = 0xff000000 & $data;
$byte1 = 0x00ff0000 & $data;
$byte2 = 0x0000ff00 & $data;
$byte3 = 0x000000ff & $data;
//same $value line as above

As far as shifting goes... I *think* this would do it:

$byte3 = $data >> 24;
$byte2 = ($data >> 16) & 0xff;
$byte1 = ($data >> 8) & 0xff;
$byte0 = $data & 0xff;

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:

Very true. I completely forgot to mention that :(

"Chris" <dmagickgmail.com> wrote in message
news:465CBC9A.1000802gmail.com...
> Steve wrote:
>> The way I handle it:
>>
>> Step 1-
>> Add SELECT SQL_CALC_FOUND_ROWS to the front of your initial query and add
>> the pagination limit to the end (LIMIT 200, 400 or whatever range you
>> want to display.)
>>
>> Step 2-
>> Do a 2nd query: SELECT FOUND_ROWS() immediately after.
>
> With a *HUGE* clause that this only works with mysql.
>
> There are other databases out there :P
>
> --
> Postgresql & php tutorials
> http://www.designmagick.com/

attached mail follows:

On Tue, May 29, 2007 10:19 am, Samuel Vogel wrote:
> I would be very interested in knowing which options, that are
> accessible
> with PHP_INI_ALL or PHP_INI_PERDIR, could be risky to allow on a
> shared
> hosting server.

php.ini_recommended is a good starting point, I think...

> I would like to allow the users to ini_set(), while disabling the
> risky
> options with php_admin_flag/value! </