A year on, how are you finding DI?

[33degrees]

The other part of the site that is having problems is their approval process.

I recently had a project approved, without every recieving an email from them; you may want to keep that in mind...

[pointbeing]

Still waiting to see a stable release of a 'finished' PHP DI container really. There's real interest here in using it, but none at all in reinventing the wheel by developing our own one.

Forgive my ignorance if I've missed one, I've been in a meeting for several months. But last time I checked Pico came complete with broken tests, so I chose to hold off...

[Ren]

Phemto v2 sounds interesting, especially if can keep it to ~100 lines. The implemtation I have atm comes in at around ~180.

[lastcraft]

Hi...

Phemto v2 sounds interesting, especially if can keep it to ~100 lines. The implemtation I have atm comes in at around ~180.

Oops, wish I'd never said that . It's 150 at the moment, so it may end up at 250.

yours, Marcus

p.s. CVS is up, but you now have to check everything out again . Looks like I'm in for an afternoon of file copying...

[33degrees]

CVS is up, but you now have to check everything out again . Looks like I'm in for an afternoon of file copying...

What's the URL for this?

[Ren]

What's the URL for this?

I'm guessing it will be http://sourceforge.net/projects/phemto/ .

[kyberfabrikken]

Until it's moved, you can get it from http://lamplib.cvs.sourceforge.net/lamplib/phemto/

[lastcraft]

Hi...

I'm guessing it will be http://sourceforge.net/projects/phemto/ .

I haven't uploaded anything yet as I want to try the SF Subversion service. Also I want to get some SimpleTest fixes out and contact Pawel (of Pico) again, so it willbe a few weeks before I code the next version. I'll post a new thread once I have it back up.

yours, Marcus

[Dr Livingston]

Sorry for taking so long...

> the factories could be locators as well, so it doesn't feel accurate.

Nope, the idea doesn't feel right to me either, some how though I can't put the explanation into words (yet)

> Was the ugly-part a joke, or do you really find the solution unsatisfactory?

Yer, the script I posted is ugly as it stands and I have since done a better implementation of it; I knew that I could... I just hadn't found the time back then, so now I'm a lot happier with the result.

include_once( 'configs/configs.php' );

// ...
// declare dependencies
        Component::set( 'logger' );
        Component::set( 'configs' );
        Component::set( 'request' );
        
// note, i need to wrap the array with an instance of typeof IDataspace...

        Component::get( 'iconfiguration' ) -> import( new Parameters( $configs ) ); 

// later...
$db = Component::get( 'iconfiguration' ) -> get( 'db' ); // database configuration 

My appologies for reviving a dead thread btw.

[lastcraft]

Hi...

There is now some code in CVS for phemto. It's currently 173 lines of code. This is still very much alpha code and the design and features may change radically. Anyway, comments would be appreciated...

http://sourceforge.net/projects/phemto/

It's a CVS pserver checkout currently. I'll get a tarball up in a couple of days.

yours, Marcus

[Ezku]

My appologies for reviving a dead thread btw.

I'm willing to take that apology, if you're willing to post more.

I'm at a stage in my framework where I'm seeing my code infested with ugly, ugly, repetitive wiring that really doesn't belong. I'm using a standard, non-static service locator right now, but it isn't doing me much in that respect. I'd be very interested in seeing whatever solutions you've come up with for yourselves.

lastcraft: Will definitely take a look as soon as I have time.

[Ren]

Hi...

There is now some code in CVS for phemto. It's currently 173 lines of code. This is still very much alpha code and the design and features may change radically. Anyway, comments would be appreciated...

http://sourceforge.net/projects/phemto/

It's a CVS pserver checkout currently. I'll get a tarball up in a couple of days.

yours, Marcus

Hmm, I've been using a DI that the registry keys are defined a register() time. So can abuse it abit and do things like http://www.sitepoint.com/forums/show...49&postcount=1 .

Definately think DI should be at the heat of a workflow type system, just haven't explored it further.

Oh, and if want to shave a few lines...

        private function discoverInterfaces($class) {
            $interfaces = array_merge(class_implements($class), class_parents($class));
            $interfaces[] = $class;
            return $interfaces;
        } 

[sweatje]

How have people tackled the problem of LazyLoading with DI? With pico, I had to make a handle class which was aware of the container, which I think is a bad code smell. Has anyone else put more thought into this than me?

class PicoLazyProxy {
    protected $pico;
    protected $class;
    protected $path;
    protected $subject;
    public function __construct($pico, $class, $path='') {
        $this->pico = $pico;
        $this->class = $class;
        $this->path = $path;
    }
    protected function subject() {
        if (!($this->subject instanceof View)) {
            if (!class_exists($this->class)) {
                require_once $this->path.$this->class.'.php';
            }
            $this->subject = $this->pico->getComponentInstance($this->class);
        }
        return $this->subject;
    }
    public function __call($method, $args) {
            return call_user_func_array(array($this->subject(), $method), $args);
    }
} 

[lastcraft]

Hi...

Oh, and if want to shave a few lines...

I always want to shave a few lines...

private function discoverInterfaces($class) {
    if (! class_exists($class)) {
        throw new Exception("Cannot inject missing class $class");
    }
    return array_merge(
            array($class),
            class_implements($class),
            class_parents($class));
} 

Now 168 lines .

yours, Marcus

[lastcraft]

Hi...

Has anyone else put more thought into this than me?

My solution is an even uglier hack, where a locator can be loaded that shortcuts the interface discovery. I already hate it.

I don't think lazy code loading works with these automated schemes. It may be that the efficiency comes from caching the interfaces after the first run.

How are you finding Pico?

yours, Marcus

[Ren]

How have people tackled the problem of LazyLoading with DI? With pico, I had to make a handle class which was aware of the container, which I think is a bad code smell. Has anyone else put more thought into this than me?

My implementation doesn't do interface discovery, but rather relies on the key provided at register time.

class LazyLoadingLocator extends ComponentLocatorDecorator
{
    private $loaded = false;
    private $fileName;

    function __construct(ComponentLocator $locator, $fileName)
    {
        parent::__construct($locator);
        $this->fileName = $fileName;
    }

    function getInstance(DependancyInjector $injector)
    {
        if (!$this->loaded)
            $this->loaded = class_exists($this->getImplementation()) || require($this->fileName);
        return parent::getInstance($injector);
    }
} 

[sweatje]

How are you finding Pico?

I can't say I have enought experience to comment. I feel like it usually takes two or three implementations usign a project to get a reasonable feel for the ins and outs of it. I used Pico on one project for handling the automatic wiring, and it perform well in that capacity. It seemed to work well in a testing mode as well, for example I was able to make a custom "assertDispach" assertion for use with actions and verify the correct action class was instanciated and called if a given action was requested.