Re: improving object oriented / procedural combinations

On Sun, Apr 25, 2010 at 15:39, Daniel Convissor <danielc@analysisandsolutions.com> wrote: > Hi Hannes: > > On Sun, Apr 25, 2010 at 10:46:47AM +0200, Hannes Magnusson wrote: >> On Fri, Apr 23, 2010 at 21:17, Daniel Convissor >> <danielc@analysisandsolutions.com> wrote: > >> > If you're talking about the same <example>, I agree. ?If you are talking >> > about the same <programlisting>, I disagree because it will lengthen and >> > clutter the example. >> >> Take DateTime::setTime() as an example. >> It has 4 examples, all using the OO way. Duplicating the entire >> example for the procedural way feels like a useless clutter to me, > > That's funny.  I thought of the same thing as I was puttering around my > apartment this morning. > > >> even if its in a different <example>. >> Add one example (into the OO <example>) for date_time_set() which is >> identical to the last ::setTime() example and a comment above it, >> mentioning it, should be enough. > > What seems clearest to me is to have Example #1 be drop dead simple use > case and be composed of an OOP programlisting, a procedural > programlisting and finally the screen output.  Any further examples will > only be in OOP.  How does that sound? Good, but shouldn't it be in the same progrramlisting, in seperate examples? >> > Perhaps: >> > ? ?public int mysqli->affected_rows >> > >> > Or if it's static: >> > ? ?public int mysqli::affected_rows >> > >> >> That looks great (would be mysqli::$affected_rows for static though.. ;)) > > The trick is what's the combination of XML and rendering needed to get > there.  I imagine the stuff that does this is in doc-base.  Any leads on > where to look will be appreciated, please. Just makeup some fun markup and we'll teach PhD it. -Hannes