Re: [PHP-DOC] Re: [PHP-DEV] "waldschrotts guide to nifty references" - manualpagedraft, version 0.9b From: Hartmut Holzgraefe ( <email protected>) (( <email protected>))
Date: 08/19/00

Stanislav Malyshev wrote:
>
> HH(>> 1) finding information about internals, esp. extension interface to
> HH(>> both php core and Zend is not easy (yet), even if you have access
> HH(>> to all the books around and i would welcome a manual part dedicated
> HH(>> to this special topic
>
> It will be easier (AFAIK Zend docs are in the way). But I strongly
> disagree it belongs to PHP manual. It is huge even now. We might have
> another book, called "Developer's reference guide" - that would be
> logical. Maybe somebody knowing how those DSSL's work should start it now,
> so that when the content arrives it could be put in...
>
> HH(>> 2) as long as we do not have seperate tutorial and programmers and
> HH(>> users guide and reference but only the one and only manual it
> HH(>> should contain as much information as possible as looking through
> HH(>> the 1000 other places will almost always end up in looking at
> HH(>> 999 of them and missing the one you really needed
>
> So we need to start that users guide and reference guide and whatever, not
> bloat the manual.
>
> HH(>> putting as much as possible into the manual won't harm as long
> HH(>> as we manage to keep it devided in clear parts and sections
>
> Yes it would. It would become so huge that you won't be able to find
> anything there without a search engine. Structuring information was not
> invented just for fun. Imagine all your Perl or C or Java programming
> books now became one book called "Java manual" or "Perl manual". And then
> try to find there some tiny part.

Perl is a very bad example because i do not have any of
the Camel, Dromedar ... books
but i know them from work and they are a complete mess
IMHO where searching somethings really is a pain
(even getting all the books into one place if you search
for something you don't remember which book it was in
can become an interesting task if the office is big
enough ;)

regarding structuring of information it doesn't matter
if we have different <book>s or one big <book> with
different <part>s as long as as much core information is
available in a structured way in _one_ place as possible

(i agree that it is not practical to have them printed
 out in one piece, but that's another story)

(a lack of structure in the function reference itself
 is another story that will hopefully continue soon)

there is still enough room for additional howtos, articles,
books and things but this shouldn't stop anyone from adding
stuff and even additional <parts> to the core manual itself
if he wants to 

--
Harmut Holzgraefe        hartmut <email protected>