Hannes Magnusson wrote:
The various variations of num_rows looks awkward and confusing, all the various methods and properties return exactly the same thing right? So as far as the user is considered these are all aliases to each other?
Yes agreed, I guess I was highlighting the fact that you can get the same info in two ways. So, what is the recommended PHP style, to use a property directly or use the accessor methods - I would have thought the latter? Whichever is the recommended way we keep, and lose the other one. I will also ask the connector guys here what they recommend.
At the moment, in the live docs, the property is documented but not the method. However, the code seems to imply the method is available.
Although the table contains a great value it is huge and not something that people will "navigate", but I guess there is no real way around it.
There is no way around it as if we are looking up a function (procedural interface) as we may have no idea of what class it is associated with, so unfortunately we can't split the table on a per-class basis.
I don't think its worth it to implement it as a first child to a <book>, its to huge to be of any use there - besides the fact http://no.php.net/mysqli already lists most of it. Maybe an appendix ("Alias listing" or whatever) is most appropriate?
OK, so as I understand it from previous discussions this table can't go in book.xml. However, I think we could have a link on that page just above the "MySQLi — The MySQLi class" bullet point. The link could be called "MySQLi Classes, Methods and Functions Index", "Method and Function Equivalence Table" or something similar. We can tweak that later I guess.
Do we have the technology to generate this table automatically? :) Many thanks, Tony
