Justtechjobs.com Find a programming school near you






Online Campus Both


php4-beta | 199912

Re: [PHP4BETA] cvs: /php4 TODO From: Thies C. Arntzen (thies <email protected>)
Date: 12/23/99

On Thu, 23 Dec 1999, Sascha Schumann wrote:

> On Thu, Dec 23, 1999 at 05:17:12PM +0100, Thies C. Arntzen wrote:
> > On Thu, 23 Dec 1999, Sascha Schumann wrote:
> >
> > > On Thu, Dec 23, 1999 at 03:19:27PM -0000, Thies C. Arntzen wrote:
> > > > thies Thu Dec 23 10:19:27 1999 EDT
> > > >
> > > > Modified files:
> > > > /php4 TODO
> > > > Log:
> > > > clean up basic_functions
> > > >
> > > >
> > > > Index: php4/TODO
> > > > diff -u php4/TODO:1.27 php4/TODO:1.28
> > > > --- php4/TODO:1.27 Thu Dec 23 07:52:11 1999
> > > > +++ php4/TODO Thu Dec 23 10:18:56 1999
> > > > @@ -3,6 +3,9 @@
> > > >
> > > > global
> > > > ------
> > > > + * let every module (source-file) have it's own module & function_entry
> > > > + block. Right now the math functions are in math.c but the corresponding
> > > > + function-entries are in basic_functions.
> > >
> > > That's not a good idea. What do you gain by doing so?
> > > Nothing. What do you lose? The module startup process will be
> > > slowed down. The source files will never be used alone, so it
> > > makes sense to save the startup time and merge major data
> > > structures in one place.
> >
> > module startup-time should not be that a big issue, 'cause it's only done
> > once -plus- i don't think it would even be measureable if we did split it
> > further. (how many cycles would we loose?)
>
> Every lost cycle matters, because they sum up. We are
> currently still in the make-it-work phase, but we definitely
> should not try to slow down PHP.

sascha, we're talking about cycles not usecs here.

our no 1 goal is stability - making things "as-modular-as-possible" will
usually make things better/more stable.

>
> > the point of splitting it further is purely to make the modules easier to
> > maintain and support. the current ext/standard is simply not consistent:
> > dir.c has it's own function_entry whereby math.c does not. i dont want to
> > attack this in this very second, but i think it [wcs]ould be a nice goal.
>
> If you want to work on making it more consistent, then merge
> the function_entry back from dir.c into basic_functions.c. If
> you have them all in one place, they are easy to maintain and
> support.

i disagree 99,5%. i think it's bad that for example info.c has to register
it's constants in basic_functions.c. what makes a module worth so that it
is allowed it's own module entry? if it needs a some globals? if it has to
register it's own class? if it needs external dependicies? what you're
saying is that everything in ext/standard should make itself known via
basic_functions?

just take the TODO out if you like (i'll keep it on my mind).

tc

>
> --
>
> Regards,
>
> Sascha Schumann
> Consultant
>
>

Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!"
Digital Collections Phone +49 40 235350 Fax +49 40 23535180
Hammerbrookstr. 93 20097 Hamburg / Germany 

-- 
PHP 4.0 Beta Mailing List <http://www.php.net/version4/>
To unsubscribe, e-mail: php4beta-unsubscribe <email protected>
For additional commands, e-mail: php4beta-help <email protected>
To contact the list administrators, e-mail: php4beta-admin <email protected>