<part id="internals2">
<title>&Internals2;</title>
&internals2.intro;
&internals2.buildsys.index; <!-- configure options, ext_skel,
config.m4, config.w32, static vs dynamic builds -->
&internals2.structure.index; <!-- ext_skel, module structure,
globals, lifecycle, tests -->
&internals2.memory.index; <!-- management, persistence, TSRM -->
&internals2.variables.index; <!-- zval, hashtable, references,
constants -->
&internals2.functions.index; <!-- defining, arguments, return
values, passthru, aliasing -->
&internals2.objects.index; <!-- classes, inheritance,
properties, methods, method-function mapping -->
&internals2.resources.index; <!-- defining, creating,
retrieving, destroying -->
&internals2.ini.index; <!-- defining, retrieving, changing
-->
&internals2.streams.index; <!-- using, wrappers, contexts,
filters -->
<!-- grab the PDO section from &Internals; here? -->
&internals2.apiref.index; <!-- full index of all APIs,
constants, macros, etc. -->
&internals2.ze1.index; <!-- quick list of major
differences, short discussion re: OOP -->
&internals2.ze3.index; <!-- quick discussion of major
changes, some details on Unicode -->
</part>
My thinking is to document ZE2 completely, since the differences
between 1 and 2 are small enough for the existing internals section
to be of use to anyone writing for 1, and 3 can be more fully
documented later (something I'm willing to take on as well).
If I'm given a thumbs-down on this way of doing things, I'll take
the material I've written already and use it to update the existing
internals section, but I think this method has the best chance of
giving people the truly comprehensive online reference we've lacked
for extension writing up to this point.
Hello Gwynne,
Sounds good. Many times silence on this list means "Sounds good" and
internals isn't too keen on defining a structure for
documentation... :) So, go for it! Always feel free to ask questions
while documenting this and as it all progresses let's be sure
internals reviews the information too. Once the information is in
manageable and smaller pieces you'll likely have more success getting
feedback. And don't be a stranger on #php.pecl @ efnet (IRC) either.
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
