> By the way, there are many reasons for creating objects inside of other > objects. This should not be considered an exception. I don't know where > this code belongs to, so I can't clear out if it is good or bad OOP > style. I do not intend to public judge the author, but the original article is here, just for proper credit: http://www.phpro.org/tutorials/Pagination-with-PHP-and-PDO.html > Just think about everything in classes and objects - even return values > or other things, that you would normally consider as "volatile". (eg. a > network connection) It would be a nice exercise to practice. :) Thanks for the tip. And thanks a lot for the reply, I'm almost there... one last newbie question: When we have something like this: Class Pagination { Public static function Pagination ($limit, $total_records, $page) { $pagi_obj= new stdClass; $pagi_obj->total_pages = $total_pages; $pagi_obj->offset = $offset; $pagi_obj->limit = $limit; $pagi_obj->page = $page; return $pagi_obj; ... How can we, later, have something like this, for example: $pagination_obj=Pagination::Pagination(some params) $pagination_obj->offset; ? I mean: When we instantiate the class by doing: $pagination_obj=Pagination::Pagination(some params) We will have an object ($pagi_obj) returned where the properties of that object will be *referring* to the values passed on the method argument, right? How does those $pagi_obj properties, can then be accessible by doing $pagination_obj->offset; ? I mean, they are attributes of our stdClass object (aka pagi_obj), and they are not attributes of our Pagination class, or are they? Thanks in advance, Márcio -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php