Re: [PHP4BETA] cvs: /php4 TODO

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