tags:

views:

26

answers:

1

Hey,
I have two separate objects, a main and a "child". Its physically not a real child object, because I add the whole parent through the constructor to the child.

Like this:

class core
{

    public function __get($class)
    {
        $this->load($class);
    }

    public function load($class, $file = null, $lib = true)
    {
        if($file == null)
            $file = $class;

        if($lib == true)
            include(LIBPATH.$file.PHP);
        else
            include(SYSPATH.$file.PHP);

        $this->$class = new $class($this);
    }

}

And the "child":

class Child implements myStruct
{
    public function __construct($obj)
    {
         $this->obj =& $obj;
    }
}

Is this as ugly as i think, or is this solution acceptable?

+3  A: 

It's definitely suboptimal. First:

$this->obj =& $obj;

There is no need for this. As of PHP 5, objects are refereed to in user space through references. When you copy an object, you're actually copying a reference. You can drop the reference operator here: $this->obj = $obj.

Look spl_autoload for autoloading classes. It's not equivalent to what you're doing -- you're using some kind of container to hold references to objects (and only one object per class), but I suspect it's what you want.

Artefacto
I consider that spl_autoload is not good for that what I want, because the core class needs to load several objects. Often stored in different folders
Nort
You can put those different folders in the included path, or you can pass `spl_autoload_register` a custom function that implements your logic.
Artefacto