By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,348 Members | 1,397 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,348 IT Pros & Developers. It's quick & easy.

Functions v includes

P: n/a

I am new to php and am looking for some quick "get up and go" help.

What would the arguments for and against be for function declarations v
simple include?

e.g

<?php
include("myfunc.php"); // declares a function "myfunc".
myfunc("hello");
?>

and

<?php
include("myfunc.php"); // just a bunch of php code with no function
?>

Does PHP cache the functions? Must functions be included on all pages
which use them? The plethora of web resources makes some of this a
trifle confusing and difficult/time consuming to pin down, so any best
practice pointers much appreciated.

Would you keep functions & includes seperate from the main pages? is it
then necessary to specify a fully qualified name when including them or
should one just set the include_path in a header? Can the include path
just be set once for a single session? or in every file which references
includes? Can you recommend a web resource which covers this type of stuff?

Feb 16 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On 16 Feb, 13:00, Richard <rgr...@gmail.comwrote:
I am new to php and am looking for some quick "get up and go" help.

What would the arguments for and against be for function declarations v
simple include?

e.g

<?php
include("myfunc.php"); // declares a function "myfunc".
myfunc("hello");
?>

and

<?php
include("myfunc.php"); // just a bunch of php code with no function
?>

Does PHP cache the functions? Must functions be included on all pages
which use them? The plethora of web resources makes some of this a
trifle confusing and difficult/time consuming to pin down, so any best
practice pointers much appreciated.

Would you keep functions & includes seperate from the main pages? is it
then necessary to specify a fully qualified name when including them or
should one just set the include_path in a header? Can the include path
just be set once for a single session? or in every file which references
includes? Can you recommend a web resource which covers this type of stuff?
Think furthr than functions. Create classes with methods then
instantate objects.

Feb 16 '07 #2

P: n/a
Richard wrote:
>
I am new to php and am looking for some quick "get up and go" help.

What would the arguments for and against be for function declarations v
simple include?

e.g

<?php
include("myfunc.php"); // declares a function "myfunc".
myfunc("hello");
?>

and

<?php
include("myfunc.php"); // just a bunch of php code with no
function
?>

Does PHP cache the functions?
Nope.
Every request to a certain page will cause the script to be executed again.
Maybe some smart caching is going on behind the scenes, not sure.
Most FILESYSTEMS however are able to cache files in memory, so the disk-IO
is eliminated needed to get the filecontant of your PHP scripts.

This happens behind your back, so you don't need to enforce it somehow (that
is: on every system I saw)

Must functions be included on all pages
which use them?
Yes.
PHP doesn't care if your function is made available to PHP via a direct
declaration in your script, or that the function is included.
You might best think of includes as being put right into place into the
mainscript, as if you putted them there.

The plethora of web resources makes some of this a
trifle confusing and difficult/time consuming to pin down, so any best
practice pointers much appreciated.
My best practise goes like this:
In every script include first a small general file that sets some important
settings. I name such file often ini_settings.php.
It contains stuff like:
- how are session handled (Database or flatfile (default) or memory)
- What is the include_path?
- an errorhandler
etc. That kind of stuff.

And I have (sometimes multiple) function files, boringly named
functions.php, that contains all functions I use in a certain project.
If you have a lot of functions, it might make sense to break them up
logically in different files. Up to you and your requirements.

Then from php:
require_once("../ini_settings.php"); // <-- That path is coded relatively
require_one("myDateFunctions.php"); // Will be include based on include_path
as defined in ini_settings.php.

One a sidenote:
I was/am never much of a speedfreak, and prefer having clean code above fast
code, so I don't mind putting all functions in one big includefile that is
included everewhere.
In most cases: If your app is slow, the reason is not a large includefile,
but bad database-design/repetitive queries/etc.
>
Would you keep functions & includes seperate from the main pages?
What do you mean by that?
All pages that need functionality that is in your includefile should have
access to it of course.

is it
then necessary to specify a fully qualified name when including them or
should one just set the include_path in a header?
You don't set the includepath in the header (not the http-header).
I think you mean 'above the rest of the script'.

I like setting the includepath, because it safes me the headache of thinking
up the relative path to the file. And using the absolute path has the
irritating side effect that moving your app forces you to check them all.
So keep the include_path in one place, for ease of use and migrating. (In my
example it is defined in ini_settings.php)

Can the include path
just be set once for a single session?
Yes, if you want. Store the path in the $_SESSION.
I don't see the advantage, but I don't know your application of course.

or in every file which references
includes?
I do not understand that question. :-/

Can you recommend a web resource which covers this type of
stuff?
All the above, which was just published on this great resource:
comp.lang.php.
;-)

On a sidenote: If you feel comfortable with OO, you can also design your
application with objects. This leads to a very different kind of
programming, but also let you design in a neat way. It is a matter of taste
what you prefer. Personally I like both. :P

Hope that helps.

Regards,
Erwin Moller
Feb 16 '07 #3

P: n/a
"Captain Paralytic" <pa**********@yahoo.comwrites:
On 16 Feb, 13:00, Richard <rgr...@gmail.comwrote:
>I am new to php and am looking for some quick "get up and go" help.

What would the arguments for and against be for function declarations v
simple include?

e.g

<?php
include("myfunc.php"); // declares a function "myfunc".
myfunc("hello");
?>

and

<?php
include("myfunc.php"); // just a bunch of php code with no function
?>

Does PHP cache the functions? Must functions be included on all pages
which use them? The plethora of web resources makes some of this a
trifle confusing and difficult/time consuming to pin down, so any best
practice pointers much appreciated.

Would you keep functions & includes seperate from the main pages? is it
then necessary to specify a fully qualified name when including them or
should one just set the include_path in a header? Can the include path
just be set once for a single session? or in every file which references
includes? Can you recommend a web resource which covers this type of stuff?

Think furthr than functions. Create classes with methods then
instantate objects.
Classes haven't even entered the picture yet.
Feb 16 '07 #4

P: n/a
Erwin Moller
<si******************************************@spam yourself.comwrites:
Richard wrote:
>>
I am new to php and am looking for some quick "get up and go" help.

What would the arguments for and against be for function declarations v
simple include?

e.g

<?php
include("myfunc.php"); // declares a function "myfunc".
myfunc("hello");
?>

and

<?php
include("myfunc.php"); // just a bunch of php code with no
function
?>

Does PHP cache the functions?

Nope.
Every request to a certain page will cause the script to be executed
again.
I thought so.
Maybe some smart caching is going on behind the scenes, not sure.
Most FILESYSTEMS however are able to cache files in memory, so the disk-IO
is eliminated needed to get the filecontant of your PHP scripts.

This happens behind your back, so you don't need to enforce it somehow (that
is: on every system I saw)

Must functions be included on all pages
>which use them?

Yes.
PHP doesn't care if your function is made available to PHP via a direct
declaration in your script, or that the function is included.
You might best think of includes as being put right into place into the
mainscript, as if you putted them there.
Macro substitution really. ok.
>
The plethora of web resources makes some of this a
>trifle confusing and difficult/time consuming to pin down, so any best
practice pointers much appreciated.

My best practise goes like this:
In every script include first a small general file that sets some important
settings. I name such file often ini_settings.php.
It contains stuff like:
- how are session handled (Database or flatfile (default) or memory)
- What is the include_path?
- an errorhandler
etc. That kind of stuff.
ok, and straightforward enough. Nothing really special to PHP there.
>
And I have (sometimes multiple) function files, boringly named
functions.php, that contains all functions I use in a certain project.
If you have a lot of functions, it might make sense to break them up
logically in different files. Up to you and your requirements.
probably a good idea to seperate them to reduce load requirements i guess.
>
Then from php:
require_once("../ini_settings.php"); // <-- That path is coded relatively
require_one("myDateFunctions.php"); // Will be include based on include_path
as defined in ini_settings.php.
fine.
>
One a sidenote:
I was/am never much of a speedfreak, and prefer having clean code above fast
code, so I don't mind putting all functions in one big includefile that is
included everewhere.
In most cases: If your app is slow, the reason is not a large includefile,
but bad database-design/repetitive queries/etc.
>>
Would you keep functions & includes seperate from the main pages?

What do you mean by that?
All pages that need functionality that is in your includefile should have
access to it of course.
Simple directory question : the answer is obvious enough - yes. Create a
forms and a library directory and add them to the include path.
>
is it
>then necessary to specify a fully qualified name when including them or
should one just set the include_path in a header?

You don't set the includepath in the header (not the http-header).
I think you mean 'above the rest of the script'.

I like setting the includepath, because it safes me the headache of thinking
up the relative path to the file. And using the absolute path has the
irritating side effect that moving your app forces you to check them all.
So keep the include_path in one place, for ease of use and migrating. (In my
example it is defined in ini_settings.php)

Can the include path
>just be set once for a single session?

Yes, if you want. Store the path in the $_SESSION.
I don't see the advantage, but I don't know your application of
course.
to avoid the meed to call to set the include path in every file which
needs to include files. Am I confusing myself? Must the include path be
set in an ini file which is included in every page which makes use of
such includes?
>
or in every file which references
>includes?

I do not understand that question. :-/
Hopefully clearer above :/
>
Can you recommend a web resource which covers this type of
>stuff?

All the above, which was just published on this great resource:
comp.lang.php.
;-)

On a sidenote: If you feel comfortable with OO, you can also design your
application with objects. This leads to a very different kind of
programming, but also let you design in a neat way. It is a matter of taste
what you prefer. Personally I like both. :P
I will move to objects but am just getting a feel for php first and its
libraries etc.
>
Hope that helps.
It has been a GREAT help, thanks.
>
Regards,
Erwin Moller

--
Feb 16 '07 #5

P: n/a
Richard wrote:

<snip>
> Can the include path
>>just be set once for a single session?

Yes, if you want. Store the path in the $_SESSION.
I don't see the advantage, but I don't know your application of
course.

to avoid the meed to call to set the include path in every file which
needs to include files. Am I confusing myself? Must the include path be
set in an ini file which is included in every page which makes use of
such includes?
Well, you can set the includepath in php.ini, but that has the problem that
(on most hostingsenvironments) your php.ini settings are used in every site
that uses PHP. Not really neat.

That is why I set them explicitly for each project in a simple includefile.

And I expect (very personal opinion) that your ARE confusing yourself by
making the included scripts session dependent.
If you design carefully you can simply include the functions you need
everywhere, and just call them when needed.
How I see it: You are fixing a speedproblem that isn't even there, as far as
I can judge of course.

As I mentioned in my former posting: almost all speedproblems with PHP are
databaserelated, and that is not PHP's fault. :-)

But maybe I misjudge, and you have a a dozen of includefiles of 5 megabyte.
Then it makes sense to be more picky, but if they stay under 100K, I
wouldn't worry too much...
>
>>
or in every file which references
>>includes?

I do not understand that question. :-/

Hopefully clearer above :/
>>
Can you recommend a web resource which covers this type of
>>stuff?

All the above, which was just published on this great resource:
comp.lang.php.
;-)

On a sidenote: If you feel comfortable with OO, you can also design your
application with objects. This leads to a very different kind of
programming, but also let you design in a neat way. It is a matter of
taste what you prefer. Personally I like both. :P

I will move to objects but am just getting a feel for php first and its
libraries etc.
Good. No need to dive into objects yet.
Anything an object can do, you can write in another way and approach it in
the good old procedural way: with functions and normal logic.
If you are comfortable with procedural PHP, maybe then switch.
You actually don't need Objects in PHP, they just make your life easier once
you know them. :-)

>
>>
Hope that helps.

It has been a GREAT help, thanks.
Glad to hear that. :-)

Good luck.

Regards,
Erwin Moller
>
>>
Regards,
Erwin Moller


--
Feb 16 '07 #6

P: n/a
Erwin Moller wrote:
Richard wrote:

<snip>
>> Can the include path
just be set once for a single session?
Yes, if you want. Store the path in the $_SESSION.
I don't see the advantage, but I don't know your application of
course.
to avoid the meed to call to set the include path in every file which
needs to include files. Am I confusing myself? Must the include path be
set in an ini file which is included in every page which makes use of
such includes?

Well, you can set the includepath in php.ini, but that has the problem that
(on most hostingsenvironments) your php.ini settings are used in every site
that uses PHP. Not really neat.

That is why I set them explicitly for each project in a simple includefile.

And I expect (very personal opinion) that your ARE confusing yourself by
making the included scripts session dependent.
If you design carefully you can simply include the functions you need
everywhere, and just call them when needed.
How I see it: You are fixing a speedproblem that isn't even there, as far as
I can judge of course.

As I mentioned in my former posting: almost all speedproblems with PHP are
databaserelated, and that is not PHP's fault. :-)

But maybe I misjudge, and you have a a dozen of includefiles of 5 megabyte.
Then it makes sense to be more picky, but if they stay under 100K, I
wouldn't worry too much...
>> or in every file which references
includes?
I do not understand that question. :-/
Hopefully clearer above :/
>> Can you recommend a web resource which covers this type of
stuff?
All the above, which was just published on this great resource:
comp.lang.php.
;-)

On a sidenote: If you feel comfortable with OO, you can also design your
application with objects. This leads to a very different kind of
programming, but also let you design in a neat way. It is a matter of
taste what you prefer. Personally I like both. :P
I will move to objects but am just getting a feel for php first and its
libraries etc.

Good. No need to dive into objects yet.
Anything an object can do, you can write in another way and approach it in
the good old procedural way: with functions and normal logic.
If you are comfortable with procedural PHP, maybe then switch.
You actually don't need Objects in PHP, they just make your life easier once
you know them. :-)

>>Hope that helps.
It has been a GREAT help, thanks.

Glad to hear that. :-)

Good luck.

Regards,
Erwin Moller
>>Regards,
Erwin Moller

--
Great advice, Erwin.

Concerning using OOP, it is oftentimes easier to maintain more finely
tuned control on a large scale. In PHP 5, you can also specify
visibility keywords, as well as several other OOP features.

As an alternative to using PHP's include path, you could use Apache's
httpd.conf to create an aliased directory for includes. I don't
believe one can do this through .htaccess, though.

If you alias your includes directory, you can access it from anywhere
in the same way:

require_once '/aliasedDir/foobar.php';

Notice the initial / preceding the aliased directory, as that's important.

--
Curtis
Feb 17 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.