Question about why something is done the way it's done.

Hey,

Because I have nothing to do on a Friday night.  I was
looking  
through the Zend framework files to see how things were
done, and I  
had a question regarding it.

I'm going to take one part of the API and use it as an
example.  That  
being the section on URI.

We have to basic parts to this

Uri.php and a Uri directory.

I am going to take an excerpt Uri.php


/**
* Zend_Uri_Exception
*/
require_once 'Zend/Uri/Exception.php';

/**
* Zend_Uri_Http
*/
require_once 'Zend/Uri/Http.php';

/**
* Zend_Uri_Mailto
*/
require_once 'Zend/Uri/Mailto.php';


My question is revolves around they way things are being
required.

Not everyone puts the Zend framework inside their include
path.  I  
for one don't  I usually put it in a lib path, and then do
something  
like
require_once(LIBBASE.'/Zend/PathToWantedFile);

Based on this, I could see instances where Uri.php might not
know  
where to find the files that it is requiring.  I remember
the adodb  
library had this problem at one time.

I would think that giving it a more direct route to the
included file  
might be a better way to do it.

require_once(dirname(__FILE__)."/Uri/Exception.php"
;);
require_once(dirname(__FILE__)."/Uri/Http.php");
require_once(dirname(__FILE__)."/Uri/Mailto.php");


Is there a reason it is done the way it is being done? 
Thoughts?

James

> My question is revolves around they way things are
being required.
> 
> Not everyone puts the Zend framework inside their
include path.  I for 
> one don't  I usually put it in a lib path, and then do
something like
> require_once(LIBBASE.'/Zend/PathToWantedFile);
> 

That is one of the requirements of the framework, you can
find it in the
installation section of the readme
(http://framework.zend.com/svn/framework/trunk/README.txt
) or buried in
the docs under the controller/boostrap section... it should
probably be
more prominent perhaps in a Requirement section of the
manual.

In any case, the Zend Framework is built as a cohesive,
loosely coupled
set of components, not as an application but as a library. 
Having that
in mind, to me, leaning on include_path to reduce the number
of function
  calls that would be required to even find subordinate
files/classes is
a "Good Thing".

Perhaps there are other lines of thinking on the matter out
there, but
since its friday night and I havent given that much thought
to it, thats
my limited perspective ;)

-ralph

I guess from the "readme" section I can see your
point, you're told  
to put it somewhere, and are expected to do that.  In my
apps I tend  
not to throw libraries into common include_path mostly for
version  
compatibility, I like to put it in the application
hierarchy, and  
call things directly.  I could add it to the include_path
with  
set_include_path(), but I like libraries being at the head
of the  
include path and the common stuff at the end, but still want
the  
current working directory to be first, and in order to do
that you  
need to rip apart the include path and re-build it  (maybe I
should  
just build a function to do that).

I do also see less function calling as being good, but i
guess it  
really depends on how memory intensive dirname() really is. 
(it  
can't be that much can it?)

Anyway, thanks for the perspective.

James

On Apr 27, 2007, at 11:45 PM, Ralph Schindler wrote:

>
>> My question is revolves around they way things are
being required.
>> Not everyone puts the Zend framework inside their
include path.  I  
>> for one don't  I usually put it in a lib path, and
then do  
>> something like
>> require_once(LIBBASE.'/Zend/PathToWantedFile);
>
> That is one of the requirements of the framework, you
can find it  
> in the
> installation section of the readme
> (http://framework.zend.com/svn/framework/trunk/README.txt
) or  
> buried in
> the docs under the controller/boostrap section... it
should  
> probably be
> more prominent perhaps in a Requirement section of the
manual.
>
> In any case, the Zend Framework is built as a cohesive,
loosely  
> coupled
> set of components, not as an application but as a
library.  Having  
> that
> in mind, to me, leaning on include_path to reduce the
number of  
> function
>  calls that would be required to even find subordinate
files/ 
> classes is
> a "Good Thing".
>
> Perhaps there are other lines of thinking on the matter
out there, but
> since its friday night and I havent given that much
thought to it,  
> thats
> my limited perspective ;)
>
> -ralph
>