Putting everything in a function

MarkR

Hi all.

When writing PHP, I put all nontrivial code in a function.

That's to say, all code which uses a variable (except for superglobals etc), goes inside a function, even if it's not a very interesting one.

This is because a function is the ONLY way to scope variables, otherwise they hang around long after you no longer need them.

I also use global variables sometimes, but fairly sparingly (e.g. having a global $db database connection object is pretty useful).

Comments?

Mark

Weedpacket

I often end up with lots of little functions also, but for a different reason....I'm not that concerned about scoping issues - if I'm worried about leaving large lumps of redundant data sitting around I unset the variables responsible (what with reference counting and copy-on-write, it can be surprising how many references to the same datum there might be).

I tend to take each step in processing and think of it as a function. I might not make it a function at a time but I'll probably factor it out later.

Thing is, it usually turns out that each step can be characterised by which variables are in use, so those variables all end up in the function together, invisible from outside.

I don't use global variables much; well, ish. There might be a set of objects being passed around with some static fields set, so I guess I do have globals, but they're partitioned with class names.

Another thing is that I often think of functions in a functional programming way: ideally (unrealistically) the operation of a function should not depend on anything other than its arguments and should not affect anything other than its return value. You see what comes in and what goes out and that characterises the function completely. Obviously the rules re. OO are a bit more complex than that. Just how unrealistic that is can be illustrated by the fact that "echo" affects state beyond the function's return value, and that in a real fp language variables are constant. Still, cutting down on side-effects does simplify the bughunt

vaaaska

What Weedie says...

I really struggle with that line where I need to create a 'function' and where I can realistically add something to another class. I generally end up with a small collection of helper functions (clean_uri(), get_instance(), etc) that just don't fit in well enough with other things.

When I come across other peoples code that doesn't make use of the procedural approach or OOP I pretty much tear my eyes out.

bubblenut

On a slight tangent, more on the subject of functional programming, how do people feel about a single point of return on functions. Do you think it is something which should be enforced or do you think multiple points of return can be easier to understand?

NogDog

bubblenut wrote:
On a slight tangent, more on the subject of functional programming, how do people feel about a single point of return on functions. Do you think it is something which should be enforced or do you think multiple points of return can be easier to understand?

I don't know what the current "best practices" opinion is on this, but I generally don't worry about it with smaller functions (the sort where you can pretty much see the entire structure/flow with one look), but I usually do try to have a single return when I create larger functions. (Of course, when they get that big, I might want to start considering whether it should be broken up into multiple functions. 🙂 )

Weedpacket

Having experienced Pascal first-hand, I much prefer being allowed to return from a function ad lib. The extra control structures I'd otherwise need to skip over and around the rest of the code just to get to the single point of return feel like wasted effort ("I know what the answer is! Why do I have to keep working on the problem?!").

But yeah, if it's getting that big I'll start factoring out chunks. If I'm going to be exiting from a function at several points, they should be obvious places to exit from (not, e.g., buried three ifs and a while deep inside a switch case).

But by the same token I typically find myself implementing tail recursion. After writing explicit code to handle the simple cases, and after writing more code that reduces more complex cases to simpler ones, the most natrual thing for me to do is finish the case with "return foo($blah);" where foo() is the function I'm writing. Maybe I should go back later and rewrite that into a loop, but I never seem to do so: is the extra complication worth it? Going from

function foo($blah)
{
    if($blah is simpleenough)
    {
        // do stuff
        return $resultofdoingstuff;
    }
    // Pile o' simplification
    return foo($simplifiedblah);
}

function foo($blah)
{
	while(!($blah is simpleenough))
    {
	    // Pile o' simplification
		$blah = $simplifiedblah;
    }
    // do stuff
    return $resultofdoingstuff;
}

dalecosp

# grep function * | grep "(" | wc -l; cd ./functions-dir && grep function * | grep "(" | wc -l
19
118

Looks like I've used a few, anyway.... :rolleyes:

Weedpacket

Something that's cropped up for me here.

I'm refactoring some old code, and there is a class with a "$type" field, which oddly enough describes what "type" of object this is (its value is drawn from a bunch of defined constants). This field is often used in switches so that different things are done depending on what $type the object being processed is. This sort of pattern is used in a few different places.

Now, clearly enough, it seems like it would make sense the current class abstract and create subclasses for each type - pulling the contents of these switches into the subclasses.

All well and good (once I track down which local variables are being used within each case, and make them method parameters - more tidying could happen later).

But what if a given class has two such fields - independent of each other? I don't have multiple inheritance. And there are one or two lines of the "$foo->type = FOOCLASS_TYPE1;" variety. I can't set $this to something. This could get sticky.

vaaaska

Just out of curiousity...how would other languages solve these problems? I'm sort of guessing here, but it's an issue that simply won't have a single simple answer?

laserlight

Just out of curiousity...how would other languages solve these problems? I'm sort of guessing here, but it's an issue that simply won't have a single simple answer?

C++ has multiple inheritance. I think implementing multiple interfaces would also solve such a problem, and both Java and PHP 5 have that language feature.

As for PHP 4, I suspect that this may mean selecting one of the "types" to use with composition.

Weedpacket

laserlight wrote:
PHP 5 [has] that language feature.

True; the problem is though that interfaces don't contain code. So what I end up with is an overall abstract class that declares the methods and a bunch of empty auxiliary interfaces to tag the classes that eventually implement the abstract class. That's not a problem, but if two such classes happen to have the identcal method that method has to be duplicated in both. I find that inelegant.

At this point I wish one could write

class foo extends abstract_class implements wibble, womble
{
include('implementation_of_wibble.php');
include('implementation_of_womble.php');
//...
}

class bar extends abstract_class implements wibble,woggle
{
include('implementation_of_wibble.php');
include('implementation_of_woggle.php');
//...
}

bubblenut

Weedpacket wrote:
At this point I wish one could write

Horray for mixins!

Weedpacket

bubblenut wrote:
Horray for mixins!

And that links across to Aspect-oriented programming which means I don't have an excuse to ignore the term any more.

NogDog

Weedpacket wrote:
And that links across to Aspect-oriented programming which means I don't have an excuse to ignore the term any more.

I tried reading some articles on that a couple years ago, and it seemed like a lot of ivory tower pretension that mostly went over my head. If you find any good introductory articles that even an old dog like me could understand, let me know. 🙂