Internal object orientation documentation available!

Nikita,

That's f*ckin' awesome. Thanks a lot!!!

Cheers,

Thank you, thank you, thank you all!

Am 10.06.2013 um 20:33 schrieb Nikita Popov nikita.ppv@gmail.com:

Hi internals!

We just published some rather extensive documentation on internal object
orientation:

http://www.phpinternalsbook.com/classes_objects.html

This is part of a larger project aimed at documenting the engine and
making
it accessible to new contributors.

Any feedback is appreciated!

Thanks,
Nikita

--

--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Hi internals!

We just published some rather extensive documentation on internal object
orientation:

http://www.phpinternalsbook.com/classes_objects.html

This is part of a larger project aimed at documenting the engine and
making
it accessible to new contributors.

Any feedback is appreciated!

That looks awesome; just asking: why didn't it go into
http://php.net/internals?

Well, we prefer writing in rst format than docbook.
We could link from php.net/internals to this URL as well , or , we could
convert rst to docbook, I heard about tools doing that.

Anyway, as everybody can see, it is far from beeing finished , so many more
things to say...

Julien.Pauli

--
Regards,
Mike

ER r q

--
Reeze
Sent with sparrow

在 2013年6月12日星期三，13:05，Michael Wallner 写道：

Hi internals!

We just published some rather extensive documentation on internal object
orientation:

http://www.phpinternalsbook.com/classes_objects.html

This is part of a larger project aimed at documenting the engine and making
it accessible to new contributors.

Any feedback is appreciated!

That looks awesome; just asking: why didn't it go into http://php.net/internals?

--
Regards,
Mike

On Wed, Jun 12, 2013 at 11:04 AM, Terry Ellison ellison.terry@gmail.comwrote:

We just published some rather extensive documentation on internal object
orientation:

 http://www.phpinternalsbook.**com/classes_objects.html<http://www.phpinternalsbook.com/classes_objects.html>

This is part of a larger project aimed at documenting the engine and
making
it accessible to new contributors.

This looks like an excellent beginning so thanks. A few general comments:

1. I notice that your book is "© Copyright 2013, Julien Pauli - Anthony
   Ferrara - Nikita Popov. All Rights Reserved" rather than GDFL or one of
   the CC variants of open document licences. They only issue that I see here
   is that I -- and possibly others -- might be a bit guarded in providing
   comment and input if that content was being transferred to the authors
   unconditionally. Also if you are reserving all rights then you will need
   to be careful to ensure that all the content is yours and not extracted
   from an open or other 3rd party source. Surely this going to add to your
   authoring burden?

We just put copyright here, but the final licence will definitely be
permissive and CC based.
PDFs and other final formats will be available too.

2. Wikipedia, for example, contains a lot of good in-depth explanation of
   CompSci concepts and standard patterns such as
   http://en.wikipedia.org/wiki/**Hash_tablehttp://en.wikipedia.org/wiki/Hash_table.
   You might consider the content cut: when you include basic discussion of
   101 principles (e.g. on HashTables); and when you limit
   your content to their PHP-specific implementation, with suitable
   references to the 101 stuff. Tending to the former will make the book a lot
   longer, albeit standalone. Your call, but I would have thought that the
   majority of the readership by nature will have some CompSci background and
   so want to skip the 101 stuff, or be referenced out to the appropriate
   in-depth WP or other reference.

3. What is your preferred markup format for feedback and contributions?
   E.g. do you maintain an ODF or Docbook XML under some accessible git
   repository, or is is a case of (for example)

Actually we would like to keep the lead on this project , as we are still
writing, and as you could see there is so much work still to be done, we
don't really think about feedbacks yet.
If we were about getting some feedbacks, at this stage, this would add more
work for us, and at this stage still : things may still move.

We have even not published the full TOC yet , though we (3 authors) agreed
with it.
To let you know, we started this project on November 1st 2012.

We'd like the book to be interesting for many people, whoever they are, so,
we will add chapters about more general purpose on CompuSci, though they
wont be as detailed as the true-PHP ones.

Julien.Pauli

On Wed, Jun 12, 2013 at 11:04 AM, Terry Ellison ellison.terry@gmail.comwrote:

We just published some rather extensive documentation on internal object
orientation:

 http://www.phpinternalsbook.**com/classes_objects.html<http://www.phpinternalsbook.com/classes_objects.html>

This is part of a larger project aimed at documenting the engine and
making
it accessible to new contributors.

This looks like an excellent beginning so thanks. A few general comments:

1. I notice that your book is "© Copyright 2013, Julien Pauli - Anthony
   Ferrara - Nikita Popov. All Rights Reserved" rather than GDFL or one of
   the CC variants of open document licences. They only issue that I see here
   is that I -- and possibly others -- might be a bit guarded in providing
   comment and input if that content was being transferred to the authors
   unconditionally. Also if you are reserving all rights then you will need
   to be careful to ensure that all the content is yours and not extracted
   from an open or other 3rd party source. Surely this going to add to your
   authoring burden?

This is just a legal precaution, because we are not yet exactly sure about
the publishing formats for this project. If we wanted to actually have a
(printed) book, then questions of ownership can become problematic. Anyway,
I'm pretty sure that we will publish this under a CC license eventually.

2. Wikipedia, for example, contains a lot of good in-depth explanation of

CompSci concepts and standard patterns such as
http://en.wikipedia.org/wiki/**Hash_tablehttp://en.wikipedia.org/wiki/Hash_table.
You might consider the content cut: when you include basic discussion of
101 principles (e.g. on HashTables); and when you limit
your content to their PHP-specific implementation, with suitable
references to the 101 stuff. Tending to the former will make the book a lot
longer, albeit standalone. Your call, but I would have thought that the
majority of the readership by nature will have some CompSci background and
so want to skip the 101 stuff, or be referenced out to the appropriate
in-depth WP or other reference.

We don't have particularly much "101 stuff" to cover (basically just
hashtables), in which case I think its better to include a small
introduction to the topic to make things self-contained. Also, this project
is targeted not just at developers with years of C experience, but also at
people coming from a more higher-level (PHP) background, in which case
intimate knowledge of things like hashtables probably can't be expected.

3. What is your preferred markup format for feedback and contributions?
   E.g. do you maintain an ODF or Docbook XML under some accessible git
   repository, or is is a case of (for example)

   hashtables/basic_structure.html para at line 138. Not quite true that
   "the arBucket array will never shrink down: you can not reduce a PHP
   array, you only can grow it". You can always implement your own
   resizer by realloing the arBucket array and the calling
   zend_hash_rehash() to do this. (This would be a good standard hash
   API function by the way.

Heh, how did you get to that page? Wasn't supposed to be linked anywhere,
as that chapter isn't done yet. In any case, we are writing this in RST
(reStructured Text) in a private git repo (which will be made public
sometime down the road). So if you have feedback, no need to write text in
any particular format, just point us to what wrong / missing (or any other
suggestions) and we'll fix it.

Regarding your particular example: Agree that this wasn't right in that
formulation. The text now says "while the arBuckets array automatically
grows, it will not shrink when you remove elements". I would rather not
mention the hack to implement the shrinking though, because its bad style
to directly mess with the members of the HT.

Thanks for your feedback Terry!

Nikita