Page 1 of 2

Should all functions return something?

Posted: Sun Nov 19, 2006 10:40 am
by AlexC
Hey,

Currently the way I code is to have the index.php page require_once() a load of other files which are all class/object based, so something like this:

Code: Select all

<?php

require_once( 'libpage.php' )
$libpage = new libpage();

?>
Then inside libpage.php will be a load of functions that call other functions inside the class, but non of the functions return anything. I use functions to pretty much hold/group code and the class is just a big wrapper around it.

I'm pretty sure I should not be coding like this, is it bad that I do? Should all my functions be returning something and instead of just doing:

Code: Select all

<?php

require_once( 'libpage.php' );
$libpage = new libpage();

?>
I should do:

Code: Select all

<?php

require_once( 'libpage.php' );
$libpage = new libpage();

$requested_page = $libpage->getPage();
$pagePermission = $libpage->getPermission( $requested_page );

if ( $pagePermission == 1 ) {
include_once( $requested_page );
} else {
echo 'hehe, no permission!';
}

?>
That's kinda a crap example, but you see all of that code after "$libpage = new libpage();" I would normally get the functions to do from within libpage() and the index.php file would have nothing to do with it.

Gee I really do suck at explaining things

Posted: Sun Nov 19, 2006 11:12 am
by feyd
Interacting with it allows you to build it more modular. If you don't interact with the object, all you built was a glorified function.

Re: Should all functions return something?

Posted: Sun Nov 19, 2006 12:23 pm
by Christopher
It sounds like your problem has nothing to do with functions returning something. Instead it looks like the problem is that you have namespaced sets of functions rather than refactoring you code down to a set of classes that have clear and specific responsibilities. Coding procedurally using the class construct to name space can provide some benefits, but often produces worse code than simply coding procedurally using only functions.

The code you proposed is really a Front Controller with a permission Plugin, but you need start coding OO before you will be able to see that.

Here is an old article on a couple of the basic premises of OO:

http://www.pragmaticprogrammer.com/ppll ... 98_05.html

Posted: Sun Nov 19, 2006 1:34 pm
by MrPotatoes
no. but it is best :)

set functions shouldn't return anything

fuctions that instantiate/initalize don't really need to but it's good to make sure that it worked :)

i have certain functions where all they do is make an object and include it. i don't bother returning on all functions but i know it is best to do so like feyd seyd

Posted: Sun Nov 19, 2006 2:49 pm
by timvw
MrPotatoes wrote:no. but it is best :)
Why would that be 'best'?
MrPotatoes wrote: fuctions that instantiate/initalize don't really need to but it's good to make sure that it worked :)
Sometimes it simply doesn't make sense to return a result. And if we want to notify the user that something (unexpected) went wrong, we throw an exception...

Posted: Sun Nov 19, 2006 3:12 pm
by MrPotatoes
returning 0, 1, -1 is just fine. people like me that don't want to or don't use exceptions that is a good option. what's wrong with that?

Posted: Sun Nov 19, 2006 5:15 pm
by timvw
MrPotatoes wrote:returning 0, 1, -1 is just fine. people like me that don't want to or don't use exceptions that is a good option. what's wrong with that?
It can become hard to figure out the function 'succeeded' or not..

eg: function divide ($nominator, $denominator)... What (0, -1, 1) would the function return if you use the paramters (1, 0) ? How would you figure out that this is a value that indicates an error?

Posted: Sun Nov 19, 2006 5:40 pm
by MrPotatoes
true/false. i use 0/1/-1 for function returns if there is a more complicated screw up.

if you don't get it then don't worry about it. i don't understand why you keep going after what i say when it does not answer the inital question

Posted: Sun Nov 19, 2006 5:52 pm
by Luke
MrPotatoes wrote:i don't understand why you keep going after what i say when it does not answer the inital question
Well actually, you asked him a question man...
MrPotatoes wrote:what's wrong with that?

Posted: Sun Nov 19, 2006 6:04 pm
by John Cartwright
MrPotatoes wrote:true/false. i use 0/1/-1 for function returns if there is a more complicated screw up.

if you don't get it then don't worry about it. i don't understand why you keep going after what i say when it does not answer the inital question
how would you know what the screw up is without more information? return false doesn't tell you much, throw new Exception('some detailed error') defines exactly what wen't wrong

Posted: Sun Nov 19, 2006 6:56 pm
by MrPotatoes
k. i'll make it simple

i have a function 'login'.

i'll return 0 if there is no user found
i'll return 0 if you couldn't be logged in
i'll return 1 if it worked
i'll return -1 if you are already logged in
also, i use -1 for errors where things shouldn't happen.

remember, it was only an example people. jesus christ. i use -1 SOMETIMES. 0/1 SOMETIMES. NOT ALWAYS

sure, i could be a little more descriptive with the two zeros but guess what, i know how to read code and i don't need an exception. also, i don't need PHP to hold my hand for everything. sorry, i don't care for exceptions in PHP. C# and C++ sure, but not PHP
The Ninja Space Goat wrote:
MrPotatoes wrote:i don't understand why you keep going after what i say when it does not answer the inital question
Well actually, you asked him a question man...
MrPotatoes wrote:what's wrong with that?
rhetorical questions aren't meant to be answered

Posted: Sun Nov 19, 2006 7:03 pm
by Luke
Somebody is a little sensitive about his error handling... 8O You have a bad day MrPotatoes?

Posted: Sun Nov 19, 2006 7:16 pm
by MrPotatoes
this isn't error handling. that's the thing. this is a return to tell me what is going on. i have a custom made error handler that doesn't use this. i use the trigger_error construct. i use return values to know whether i should trigger_error notice, fatal or whatnot.

bad day? no. i just don't like to be ganged up on.

the internet. it's serious business

Posted: Sun Nov 19, 2006 8:28 pm
by feyd
In PHP, user created functions always return something, whether you like it or not. Specifically, if the function doesn't have a return statement hit, the function returns NULL.

Posted: Sun Nov 19, 2006 11:47 pm
by John Cartwright
MrPotatoes wrote: i'll return 0 if there is no user found
i'll return 0 if you couldn't be logged in
i'll return 1 if it worked
i'll return -1 if you are already logged in
also, i use -1 for errors where things shouldn't happen.
Firstly, no one here is ganging up on you, this a discussion. If everyone agreed always there would be no need for this forum.

Secondly, this is constructive critisism. We are simply saying some shortfalls of your method. For instance, I sure would like to know the difference between having your user already logged in and errors where things shouldn't happen (lets say for error logging purposes). This sure makes hard for debugging. Also, what if someone who picks up your code and runs the function and the function simply returns false.. not very helpful.
sure, i could be a little more descriptive with the two zeros but guess what, i know how to read code and i don't need an exception. also, i don't need PHP to hold my hand for everything. sorry, i don't care for exceptions in PHP. C# and C++ sure, but not PHP
What's wrong with using exceptions in php? :? Even if you have beef with exceptions for whatever reason (I can think of only one), there are alternatives to displaying for helpful error messages. In this case, "also, i use -1 for errors where things shouldn't happen.", wouldn't a fatal error be more appropriate?

I am certainly welcoming any counter points, although I don't think "I don't care for exceptions in php" quite a valid argument in this case. Not that you have to listen to me, nor do you have to reply, but if your going to make certain points and when questioned it is curtious to justify your advise.