RE: [Phpgroupware-developers] Discussion: include/require stateme nts

[Kai Hofmann]

> > When making API calls this is surely the best way. But at 
> the same time
> > createObject/ExecMethod create the biggest overhead we have 
> as I know from
> > performance analyses.
> 
> Where is the data to support the claim?

Its in a non-GPL closed source tool called Zend Studio - but I can make
a Screenshot if you like.

> createObject sits on top of this.  It deals with some of the issues
> created by php.  Import in Java and C# (2 languages I have experience
> with) are path aware.  If we want to go down this road within phpgw I
> would suggest that the header.inc.php does a ini_set for include_path.
> Then you can also have problems where a user wants the API 
> class an gets
> the app file with the same name of vise versa

When you are using this only within a "closed" module like an application
or the api itself, this is no problem.

> > 2. You can easily see the dependencies of a source file 
> very quickly, when
> > the
> >    require statements are placed near the head of the file.
> > 3. Each source file itself knows which dependencies it has, 
> so only required
> >    files will be loaded at runtime.
> >    (This is important, because at the moment we load often 
> a lot of things
> > that
> >    are not required - which costs performance)
> > 
> 
> Examples?

The already known example is the data load of translations that
will not be used. After this has been fixed better performance analysis
could be done to find out the other bottlenecks.

> As I mentioned in my previous post Not true - require triggers a fatal
> error http://php.net/phpdevel-errors#internal.e-error
> 
> It dies at that point

And that is exacly what should happen, when the installation
is incomplete. When including modules etc. you run a
"module scanner" first, so that you know which files are there
before including them. - So no errors

> > The problem here is that the usage of include here has its 
> problems and
> > might
> > result in errors.
> 
> Not if there are the proper checks, such as above.

"!" is not a proper check, using a binary operator on strings or other
types is always error prone.


The quotes are not the parts I meant, but quoting all the lines
will not make sense here.

Greetings

   PowerStat