> 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

Reply via email to