Expansion of the coding standards

[Pieter Kokx]

Today we had a lot of discussion on IRC about expansion of the Coding
Standars for ZF 2.0. So I am putting this up here for some deeper
discussion.

The biggest problem of the current standards is that there are lots of
things that aren't addressed (mostly API-wise), some of these issues are:

* underscore_separated vs CamelCase in configuration options for components
* Singleton vs. Factory vs. new etc.
* $table->name() vs $table->getName()
* Plugin loading (though this is not directly a coding standards issue)
* Configuration of components (some components allow Zend_Config, some
just take an array, and some enforce Zend_Config)
* API obfuscation due to the usage of magic __call() methods

Also, it might be a very good idea that the CodeSniffer tool would be
re-introduced so all components get tested for compatability with the
coding standards automatically.

--
Best Regards,

Pieter Kokx
PHP Developer
Zend Framework developer

[lcrouch]

Just my $0.02 ...

In Java, I abhorred Singletons in favor of Dependency Injection with
Spring's IoC. In PHP, I find myself sliding back into Singletons ...
I'm not as anti-Singleton as I was, but I still prefer to avoid them
if I can. That being said, if there's no Dependency Injection planned
for ZF 2.0 then I'm fine with Singleton.

-L

On Wed, May 26, 2010 at 2:34 PM, Pieter Kokx <[hidden email]> wrote:

> Today we had a lot of discussion on IRC about expansion of the Coding
> Standars for ZF 2.0. So I am putting this up here for some deeper
> discussion.
>
> The biggest problem of the current standards is that there are lots of
> things that aren't addressed (mostly API-wise), some of these issues are:
>
> * underscore_separated vs CamelCase in configuration options for components
> * Singleton vs. Factory vs. new etc.
> * $table->name() vs $table->getName()
> * Plugin loading (though this is not directly a coding standards issue)
> * Configuration of components (some components allow Zend_Config, some
> just take an array, and some enforce Zend_Config)
> * API obfuscation due to the usage of magic __call() methods
>
> Also, it might be a very good idea that the CodeSniffer tool would be
> re-introduced so all components get tested for compatability with the
> coding standards automatically.
>
> --
> Best Regards,
>
> Pieter Kokx
> PHP Developer
> Zend Framework developer
>
>
>

[Vincent de Lau]

> Van: Luke Crouch [mailto:[hidden email]]
>
> Just my $0.02 ...
>
> In Java, I abhorred Singletons in favor of Dependency Injection with
> Spring's IoC. In PHP, I find myself sliding back into Singletons ...
> I'm not as anti-Singleton as I was, but I still prefer to avoid them
> if I can. That being said, if there's no Dependency Injection planned
> for ZF 2.0 then I'm fine with Singleton.
>
> -L

I'll add €0,02 ...

To be honest, I've heard about DI, but never got round to reading into it. Last week I spent some time catching up and immediately wondered why Zend_Application wasn't designed to be or use a DI container. I've even looked up the proposal and DI is mentioned, but never really worked on. There's three DI proposals lying around, but all seem kind of abandoned.

Although I lack the experience, I can see a benefit in using a central DI container. Currently in my bootstrap I have a lot of glue to make sure that Session has a Database, Database has a Cache etcetera. Also I have a lot of singletons and stuff in my Registry (which has to be set up in the bootstrap).

Vincent de Lau
 [hidden email]

[weierophinney]

-- Vincent de Lau <[hidden email]> wrote
(on Wednesday, 02 June 2010, 03:58 PM +0200):

> > Van: Luke Crouch [mailto:[hidden email]]
> >
> > Just my $0.02 ...
> >
> > In Java, I abhorred Singletons in favor of Dependency Injection with
> > Spring's IoC. In PHP, I find myself sliding back into Singletons ...
> > I'm not as anti-Singleton as I was, but I still prefer to avoid them
> > if I can. That being said, if there's no Dependency Injection planned
> > for ZF 2.0 then I'm fine with Singleton.
> >
> > -L
>
> I'll add €0,02 ...
>
> To be honest, I've heard about DI, but never got round to reading into
> it. Last week I spent some time catching up and immediately wondered
> why Zend_Application wasn't designed to be or use a DI container.
> I've even looked up the proposal and DI is mentioned, but never really
> worked on.

Actually, it is... and isn't.

Internally, it's designed such that you can _use_ a DI container in
place of the registry instance -- see the setContainer()/getContainer()
calls in the bootstrap class. By default, it uses a Zend_Registry
instance (note, not a global registry), but we didn't typehint so that
you can use a DI container if desired. Several people have done so, and
used the Symfony2 DI container.

We didn't make a requirement of having a DI container in ZF, in part due
to:

> There's three DI proposals lying around, but all seem kind
> of abandoned.

The problems encountered are either the implementations are too complex
and offer too much overhead, or they're too simplistic, and don't allow
for options such as lazy-loading. Additionally, there are some concerns
about whether DI containers or IoC really have a place in a PHP
application, where you have short-lived requests.

What we *are* doing is making sure new ZF components (and all ZF2
components) allow for DI -- i.e., they're architected in such a way that
you can inject dependencies. This tends to work well with existing PHP
DI container implementations, and helps us defer the issue of having an
implementation ourselves.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Matthew Ratzloff]

Additionally, there are some concerns 

about whether DI containers or IoC really have a place in a PHP 

application, where you have short-lived requests.

The inversion of control principles still apply for testability, but I agree that a full DI container in PHP would be doing a lot of work that's just thrown away at the end of execution.

-Matt

On Wed, Jun 2, 2010 at 7:31 AM, Matthew Weier O'Phinney <[hidden email]> wrote:

-- Vincent de Lau <[hidden email]> wrote
(on Wednesday, 02 June 2010, 03:58 PM +0200):

> > Van: Luke Crouch [mailto:[hidden email]]
> >
> > Just my $0.02 ...
> >
> > In Java, I abhorred Singletons in favor of Dependency Injection with
> > Spring's IoC. In PHP, I find myself sliding back into Singletons ...
> > I'm not as anti-Singleton as I was, but I still prefer to avoid them
> > if I can. That being said, if there's no Dependency Injection planned
> > for ZF 2.0 then I'm fine with Singleton.
> >
> > -L
>
> I'll add €0,02 ...
>
> To be honest, I've heard about DI, but never got round to reading into
> it. Last week I spent some time catching up and immediately wondered
> why Zend_Application wasn't designed to be or use a DI container.
> I've even looked up the proposal and DI is mentioned, but never really
> worked on.

Actually, it is... and isn't.

Internally, it's designed such that you can _use_ a DI container in
place of the registry instance -- see the setContainer()/getContainer()
calls in the bootstrap class. By default, it uses a Zend_Registry
instance (note, not a global registry), but we didn't typehint so that
you can use a DI container if desired. Several people have done so, and
used the Symfony2 DI container.

We didn't make a requirement of having a DI container in ZF, in part due
to:

> There's three DI proposals lying around, but all seem kind
> of abandoned.

The problems encountered are either the implementations are too complex
and offer too much overhead, or they're too simplistic, and don't allow
for options such as lazy-loading. Additionally, there are some concerns
about whether DI containers or IoC really have a place in a PHP
application, where you have short-lived requests.

What we *are* doing is making sure new ZF components (and all ZF2
components) allow for DI -- i.e., they're architected in such a way that
you can inject dependencies. This tends to work well with existing PHP
DI container implementations, and helps us defer the issue of having an
implementation ourselves.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Loïc Frering]

Hello,

I recently posted a comment concerning a DI container on Zend Framework 2.0 Requirements wiki page: http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements.

I deeply integrated Symfony DI Container into Zend Framework 1 and particularly into Zend_Application and into the dispatcher to let the container manage the controllers lifecycle and their dependencies. I have also developed an annotation loader for Symfony DI Container to allow service definition by annotation.

I ended with a really solid, highly configurable, decoupled, flexible, evolutive and testable multi-layered PHP architecture that I use in my professional and personal projects. I have also developed a Doctrine 2 integration into ZF and this multi-layered architecture with generic service and scaffolding (for forms, services, controllers and views): it works very well! You can check my code on my GitHub: http://github.com/loicfrering/losolib.

You can find an example of what can be achieve in my wiki comment or in my Github.

I'm glad to hear Matthew saying that they will continue to make Zend Framework (2) "DI enabled" and I think that if ZF2 does not provide his own DI Container (and that would be comprehensible as Symfony proposes a really good one as an external component), integration of a tier DI Container should be highly facilitated.

On Wed, Jun 2, 2010 at 5:27 PM, Matthew Ratzloff <[hidden email]> wrote:

Additionally, there are some concerns 

about whether DI containers or IoC really have a place in a PHP 

application, where you have short-lived requests.

The inversion of control principles still apply for testability, but I agree that a full DI container in PHP would be doing a lot of work that's just thrown away at the end of execution.

-Matt

On Wed, Jun 2, 2010 at 7:31 AM, Matthew Weier O'Phinney <[hidden email]> wrote:

-- Vincent de Lau <[hidden email]> wrote
(on Wednesday, 02 June 2010, 03:58 PM +0200):

> > Van: Luke Crouch [mailto:[hidden email]]
> >
> > Just my $0.02 ...
> >
> > In Java, I abhorred Singletons in favor of Dependency Injection with
> > Spring's IoC. In PHP, I find myself sliding back into Singletons ...
> > I'm not as anti-Singleton as I was, but I still prefer to avoid them
> > if I can. That being said, if there's no Dependency Injection planned
> > for ZF 2.0 then I'm fine with Singleton.
> >
> > -L
>
> I'll add €0,02 ...
>
> To be honest, I've heard about DI, but never got round to reading into
> it. Last week I spent some time catching up and immediately wondered
> why Zend_Application wasn't designed to be or use a DI container.
> I've even looked up the proposal and DI is mentioned, but never really
> worked on.

Actually, it is... and isn't.

Internally, it's designed such that you can _use_ a DI container in
place of the registry instance -- see the setContainer()/getContainer()
calls in the bootstrap class. By default, it uses a Zend_Registry
instance (note, not a global registry), but we didn't typehint so that
you can use a DI container if desired. Several people have done so, and
used the Symfony2 DI container.

We didn't make a requirement of having a DI container in ZF, in part due
to:

> There's three DI proposals lying around, but all seem kind
> of abandoned.

The problems encountered are either the implementations are too complex
and offer too much overhead, or they're too simplistic, and don't allow
for options such as lazy-loading. Additionally, there are some concerns
about whether DI containers or IoC really have a place in a PHP
application, where you have short-lived requests.

What we *are* doing is making sure new ZF components (and all ZF2
components) allow for DI -- i.e., they're architected in such a way that
you can inject dependencies. This tends to work well with existing PHP
DI container implementations, and helps us defer the issue of having an
implementation ourselves.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
Loïc Frering
[hidden email]

[Artur Ejsmont]

Sounds very exciting to me as well.

DI is really cool and PHP world should try to adopt it a bit more (well where suitable).

- easy to replace any core component (then entire framework uses your implementation instead the default one. With factories and hardcoded class names thats often not possible)

- looser coupling

- easier testability

I really like the comments and code from Loic Frering, nicely done : )

The only downsides of DI in php is you cant reuse components between requests and you have to add these nasty setters to your public API. 

Interface should not have any of that crap, you create instance, then you know what dependencies to pass. Once you have working instance you should not see any of its guts nor play around with them. Thats why i would prefer injection via constructor to be honest. I really believe you should not allow too many setters/getters in your classes "keep your privates private" ; )

ps. i have seen people doing really ugly things with the zend registry, like it was solving global state problems ...... "its a design pattern! we should store everything in it now!" ; ) hehe

Art

On 2 June 2010 17:16, Loïc Frering <[hidden email]> wrote:

Hello,

I recently posted a comment concerning a DI container on Zend Framework 2.0 Requirements wiki page: http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements.

I deeply integrated Symfony DI Container into Zend Framework 1 and particularly into Zend_Application and into the dispatcher to let the container manage the controllers lifecycle and their dependencies. I have also developed an annotation loader for Symfony DI Container to allow service definition by annotation.

I ended with a really solid, highly configurable, decoupled, flexible, evolutive and testable multi-layered PHP architecture that I use in my professional and personal projects. I have also developed a Doctrine 2 integration into ZF and this multi-layered architecture with generic service and scaffolding (for forms, services, controllers and views): it works very well! You can check my code on my GitHub: http://github.com/loicfrering/losolib.

You can find an example of what can be achieve in my wiki comment or in my Github.

I'm glad to hear Matthew saying that they will continue to make Zend Framework (2) "DI enabled" and I think that if ZF2 does not provide his own DI Container (and that would be comprehensible as Symfony proposes a really good one as an external component), integration of a tier DI Container should be highly facilitated.

On Wed, Jun 2, 2010 at 5:27 PM, Matthew Ratzloff <[hidden email]> wrote:

Additionally, there are some concerns 

about whether DI containers or IoC really have a place in a PHP 

application, where you have short-lived requests.

The inversion of control principles still apply for testability, but I agree that a full DI container in PHP would be doing a lot of work that's just thrown away at the end of execution.

-Matt

On Wed, Jun 2, 2010 at 7:31 AM, Matthew Weier O'Phinney <[hidden email]> wrote:

-- Vincent de Lau <[hidden email]> wrote
(on Wednesday, 02 June 2010, 03:58 PM +0200):

> > Van: Luke Crouch [mailto:[hidden email]]
> >
> > Just my $0.02 ...
> >
> > In Java, I abhorred Singletons in favor of Dependency Injection with
> > Spring's IoC. In PHP, I find myself sliding back into Singletons ...
> > I'm not as anti-Singleton as I was, but I still prefer to avoid them
> > if I can. That being said, if there's no Dependency Injection planned
> > for ZF 2.0 then I'm fine with Singleton.
> >
> > -L
>
> I'll add €0,02 ...
>
> To be honest, I've heard about DI, but never got round to reading into
> it. Last week I spent some time catching up and immediately wondered
> why Zend_Application wasn't designed to be or use a DI container.
> I've even looked up the proposal and DI is mentioned, but never really
> worked on.

Actually, it is... and isn't.

Internally, it's designed such that you can _use_ a DI container in
place of the registry instance -- see the setContainer()/getContainer()
calls in the bootstrap class. By default, it uses a Zend_Registry
instance (note, not a global registry), but we didn't typehint so that
you can use a DI container if desired. Several people have done so, and
used the Symfony2 DI container.

We didn't make a requirement of having a DI container in ZF, in part due
to:

> There's three DI proposals lying around, but all seem kind
> of abandoned.

The problems encountered are either the implementations are too complex
and offer too much overhead, or they're too simplistic, and don't allow
for options such as lazy-loading. Additionally, there are some concerns
about whether DI containers or IoC really have a place in a PHP
application, where you have short-lived requests.

What we *are* doing is making sure new ZF components (and all ZF2
components) allow for DI -- i.e., they're architected in such a way that
you can inject dependencies. This tends to work well with existing PHP
DI container implementations, and helps us defer the issue of having an
implementation ourselves.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
Loïc Frering
[hidden email]

[drm-4]

Artur Ejsmont wrote:
> Sounds very exciting to me as well.
>
> DI is really cool and PHP world should try to adopt it a bit more
> (well where suitable).

DI as a concept is over-hyped and overrated and -imho- just a buzzword.
I'd rather talk about design by contract, and how we get that sorted
throughout the API, because that is essentially what DI is all about;
iow what DI problems all boil down to.

And a DI container is just another registry, let not over-dramatize it ;)


drm / Gerard

[keith Pope-4]

On 3 June 2010 21:26, drm <[hidden email]> wrote:

> Artur Ejsmont wrote:
>>
>> Sounds very exciting to me as well.
>>
>> DI is really cool and PHP world should try to adopt it a bit more (well
>> where suitable).
>
> DI as a concept is over-hyped and overrated and -imho- just a buzzword. I'd
> rather talk about design by contract, and how we get that sorted throughout
> the API, because that is essentially what DI is all about; iow what DI
> problems all boil down to.
>
> And a DI container is just another registry, let not over-dramatize it ;)

Maybe DI containers will be less important as PHP add features that
allow things like monkey-patching, this all comes down to the debate
whether DI containers are good in dynamic languages. I think for
containers to be useful they would need to be very clever in how they
initiate the object graph to avoid unnecessary overhead, which would
probably make them perform badly.

This of course is not to say our components should not support DI,
which is different from DI containers. I also agree that design by
contract would help greatly, I have had many occasion where I have
wanted to either mock from an interface or replace a class only to
find no interface....

>
>
> drm / Gerard
>
>



--
------------
http://www.thepopeisdead.com

[Loïc Frering]

Wikipedia: "One benefit of using the dependency injection approach is the reduction of boilerplate code in the application objects since all work to initialize or setup dependencies is handled by a provider component."

Symfony's DI container definition is particularly easy and explicit. You should have a look at his documentation, it is quite interesting.

On Thu, Jun 3, 2010 at 11:14 PM, keith Pope <[hidden email]> wrote:

On 3 June 2010 21:26, drm <[hidden email]> wrote:
> Artur Ejsmont wrote:
>>
>> Sounds very exciting to me as well.
>>
>> DI is really cool and PHP world should try to adopt it a bit more (well
>> where suitable).
>
> DI as a concept is over-hyped and overrated and -imho- just a buzzword. I'd
> rather talk about design by contract, and how we get that sorted throughout
> the API, because that is essentially what DI is all about; iow what DI
> problems all boil down to.
>
> And a DI container is just another registry, let not over-dramatize it ;)

Maybe DI containers will be less important as PHP add features that
allow things like monkey-patching, this all comes down to the debate
whether DI containers are good in dynamic languages. I think for
containers to be useful they would need to be very clever in how they
initiate the object graph to avoid unnecessary overhead, which would
probably make them perform badly.

This of course is not to say our components should not support DI,
which is different from DI containers. I also agree that design by
contract would help greatly, I have had many occasion where I have
wanted to either mock from an interface or replace a class only to
find no interface....

>
>
> drm / Gerard
>
>



--
------------
http://www.thepopeisdead.com

--
Loïc Frering
[hidden email]

[drm-4]

On 6/4/2010 12:29 AM, Loïc Frering wrote:

Wikipedia: "One benefit of using the dependency injection approach is the reduction of boilerplate code in the application objects since all work to initialize or setup dependencies is handled by a provider component."

Symfony's DI container definition is particularly easy and explicit. You should have a look at his documentation, it is quite interesting.

My point is that, imo, you should see through the concept of a DI and DI container mechanism (or builder for that matter), and look at the actual design issues that a DI is trying to solve. What you will find out (or at least, what I have gathered) is that is basically a matter of getting everything designed by-contract, and defensive programming. DI then becomes a breeze and you wouldn't need a separate component for it. An object/resource/component-builder is another issue and has in fact nothing to do with DI. That could, in ZF terms, be solved getting Zend_Application's bootstrapping method more "on-demand" and employ more lazy-load and a better unified implementation of the setOptions()-mechanism.


drm / Gerard

[Eric Clemmons]

Unless I'm entirely missing this DI discussion, doesn't ZF already implement this pattern in several components via construction & setters?

For example, I could create a mock Zend_Db_Adapter and supply it via config or via `setAdapter`.  The only thing new, to me at least, is the "container" concept, which usually exists as my own final class to wrap my Zend_Db instantiation.

--Eric

On Jun 4, 2010, at 9:30 AM, drm wrote:

On 6/4/2010 12:29 AM, Loïc Frering wrote:

Wikipedia: "One benefit of using the dependency injection approach is the reduction of boilerplate code in the application objects since all work to initialize or setup dependencies is handled by a provider component."

Symfony's DI container definition is particularly easy and explicit. You should have a look at his documentation, it is quite interesting.

My point is that, imo, you should see through the concept of a DI and DI container mechanism (or builder for that matter), and look at the actual design issues that a DI is trying to solve. What you will find out (or at least, what I have gathered) is that is basically a matter of getting everything designed by-contract, and defensive programming. DI then becomes a breeze and you wouldn't need a separate component for it. An object/resource/component-builder is another issue and has in fact nothing to do with DI. That could, in ZF terms, be solved getting Zend_Application's bootstrapping method more "on-demand" and employ more lazy-load and a better unified implementation of the setOptions()-mechanism.


drm / Gerard

[Pieter Kokx]

Yes, indeed that are the basics of DI. But this discussion isn't actually about DI itself, but about a DI container in ZF. Mostly, if you hear people talk about DI, it is always about a container instead of the principle itself.

On 04-06-10 16:34, Eric Clemmons wrote:

Unless I'm entirely missing this DI discussion, doesn't ZF already implement this pattern in several components via construction & setters?

For example, I could create a mock Zend_Db_Adapter and supply it via config or via `setAdapter`.  The only thing new, to me at least, is the "container" concept, which usually exists as my own final class to wrap my Zend_Db instantiation.

--Eric

On Jun 4, 2010, at 9:30 AM, drm wrote:

On 6/4/2010 12:29 AM, Loïc Frering wrote:

Wikipedia: "One benefit of using the dependency injection approach is the reduction of boilerplate code in the application objects since all work to initialize or setup dependencies is handled by a provider component."

Symfony's DI container definition is particularly easy and explicit. You should have a look at his documentation, it is quite interesting.

My point is that, imo, you should see through the concept of a DI and DI container mechanism (or builder for that matter), and look at the actual design issues that a DI is trying to solve. What you will find out (or at least, what I have gathered) is that is basically a matter of getting everything designed by-contract, and defensive programming. DI then becomes a breeze and you wouldn't need a separate component for it. An object/resource/component-builder is another issue and has in fact nothing to do with DI. That could, in ZF terms, be solved getting Zend_Application's bootstrapping method more "on-demand" and employ more lazy-load and a better unified implementation of the setOptions()-mechanism.


drm / Gerard

[lcrouch]

Wow, didn't mean to kick off this whole thread.

I also remember coming from Java+Spring back into PHP+ZF that PHP
didn't "feel" like it needed an IoC container the way that Java did. I
re-used a lot of the lessons in my code - lean towards composition
over inheritance and provide constructor and/or setters for class
dependencies, but never felt the need to have a DI "engine" in my PHP
or ZF code.

That being said, an IoC container is a nice way to enforce some of
those practices.

THAT being said, I also lean away from language-enforced practices
like static typing and strict member visibility.

So, I think a DI or IoC component in ZF is useful, but shouldn't be mandatory.

-L

On Fri, Jun 4, 2010 at 9:38 AM, Pieter Kokx <[hidden email]> wrote:

> Yes, indeed that are the basics of DI. But this discussion isn't actually
> about DI itself, but about a DI container in ZF. Mostly, if you hear people
> talk about DI, it is always about a container instead of the principle
> itself.
>
> --
> Best Regards,
>
> Pieter Kokx
> PHP Developer
> Zend Framework developer
>
> On 04-06-10 16:34, Eric Clemmons wrote:
>
> Unless I'm entirely missing this DI discussion, doesn't ZF already implement
> this pattern in several components via construction & setters?
> For example, I could create a mock Zend_Db_Adapter and supply it via config
> or via `setAdapter`.  The only thing new, to me at least, is the "container"
> concept, which usually exists as my own final class to wrap my Zend_Db
> instantiation.
> --Eric
> On Jun 4, 2010, at 9:30 AM, drm wrote:
>
> On 6/4/2010 12:29 AM, Loïc Frering wrote:
>
> Wikipedia: "One benefit of using the dependency injection approach is the
> reduction of boilerplate code in the application objects since all work to
> initialize or setup dependencies is handled by a provider component."
>
> Symfony's DI container definition is particularly easy and explicit. You
> should have a look at his documentation, it is quite interesting.
>
> My point is that, imo, you should see through the concept of a DI and DI
> container mechanism (or builder for that matter), and look at the actual
> design issues that a DI is trying to solve. What you will find out (or at
> least, what I have gathered) is that is basically a matter of getting
> everything designed by-contract, and defensive programming. DI then becomes
> a breeze and you wouldn't need a separate component for it. An
> object/resource/component-builder is another issue and has in fact nothing
> to do with DI. That could, in ZF terms, be solved getting Zend_Application's
> bootstrapping method more "on-demand" and employ more lazy-load and a better
> unified implementation of the setOptions()-mechanism.
>
>
> drm / Gerard
>
>

[Eric Clemmons]

The whole "use-at-will" concept keeps coming back up :)

I'm interested in seeing a practical example with zf.  I just can't think of a "problem" that it can solve right now, since this is relatively new to me.

On Jun 4, 2010, at 9:43 AM, Luke Crouch wrote:

> Wow, didn't mean to kick off this whole thread.
>
> I also remember coming from Java+Spring back into PHP+ZF that PHP
> didn't "feel" like it needed an IoC container the way that Java did. I
> re-used a lot of the lessons in my code - lean towards composition
> over inheritance and provide constructor and/or setters for class
> dependencies, but never felt the need to have a DI "engine" in my PHP
> or ZF code.
>
> That being said, an IoC container is a nice way to enforce some of
> those practices.
>
> THAT being said, I also lean away from language-enforced practices
> like static typing and strict member visibility.
>
> So, I think a DI or IoC component in ZF is useful, but shouldn't be mandatory.
>
> -L
>
> On Fri, Jun 4, 2010 at 9:38 AM, Pieter Kokx <[hidden email]> wrote:
>> Yes, indeed that are the basics of DI. But this discussion isn't actually
>> about DI itself, but about a DI container in ZF. Mostly, if you hear people
>> talk about DI, it is always about a container instead of the principle
>> itself.
>>
>> --
>> Best Regards,
>>
>> Pieter Kokx
>> PHP Developer
>> Zend Framework developer
>>
>> On 04-06-10 16:34, Eric Clemmons wrote:
>>
>> Unless I'm entirely missing this DI discussion, doesn't ZF already implement
>> this pattern in several components via construction & setters?
>> For example, I could create a mock Zend_Db_Adapter and supply it via config
>> or via `setAdapter`.  The only thing new, to me at least, is the "container"
>> concept, which usually exists as my own final class to wrap my Zend_Db
>> instantiation.
>> --Eric
>> On Jun 4, 2010, at 9:30 AM, drm wrote:
>>
>> On 6/4/2010 12:29 AM, Loïc Frering wrote:
>>
>> Wikipedia: "One benefit of using the dependency injection approach is the
>> reduction of boilerplate code in the application objects since all work to
>> initialize or setup dependencies is handled by a provider component."
>>
>> Symfony's DI container definition is particularly easy and explicit. You
>> should have a look at his documentation, it is quite interesting.
>>
>> My point is that, imo, you should see through the concept of a DI and DI
>> container mechanism (or builder for that matter), and look at the actual
>> design issues that a DI is trying to solve. What you will find out (or at
>> least, what I have gathered) is that is basically a matter of getting
>> everything designed by-contract, and defensive programming. DI then becomes
>> a breeze and you wouldn't need a separate component for it. An
>> object/resource/component-builder is another issue and has in fact nothing
>> to do with DI. That could, in ZF terms, be solved getting Zend_Application's
>> bootstrapping method more "on-demand" and employ more lazy-load and a better
>> unified implementation of the setOptions()-mechanism.
>>
>>
>> drm / Gerard
>>
>>

[Loïc Frering]

I quite agree with a use-at-will DI Container in ZF. By the way, here is a practical exemple of what can be achieve with a DI Container in a multilayered application : http://gist.github.com/425504.

On Fri, Jun 4, 2010 at 4:46 PM, Eric Clemmons <[hidden email]> wrote:

The whole "use-at-will" concept keeps coming back up :)

I'm interested in seeing a practical example with zf.  I just can't think of a "problem" that it can solve right now, since this is relatively new to me.

On Jun 4, 2010, at 9:43 AM, Luke Crouch wrote:

> Wow, didn't mean to kick off this whole thread.
>
> I also remember coming from Java+Spring back into PHP+ZF that PHP
> didn't "feel" like it needed an IoC container the way that Java did. I
> re-used a lot of the lessons in my code - lean towards composition
> over inheritance and provide constructor and/or setters for class
> dependencies, but never felt the need to have a DI "engine" in my PHP
> or ZF code.
>
> That being said, an IoC container is a nice way to enforce some of
> those practices.
>
> THAT being said, I also lean away from language-enforced practices
> like static typing and strict member visibility.
>
> So, I think a DI or IoC component in ZF is useful, but shouldn't be mandatory.
>
> -L
>
> On Fri, Jun 4, 2010 at 9:38 AM, Pieter Kokx <[hidden email]> wrote:
>> Yes, indeed that are the basics of DI. But this discussion isn't actually
>> about DI itself, but about a DI container in ZF. Mostly, if you hear people
>> talk about DI, it is always about a container instead of the principle
>> itself.
>>
>> --
>> Best Regards,
>>
>> Pieter Kokx
>> PHP Developer
>> Zend Framework developer
>>
>> On 04-06-10 16:34, Eric Clemmons wrote:
>>
>> Unless I'm entirely missing this DI discussion, doesn't ZF already implement
>> this pattern in several components via construction & setters?
>> For example, I could create a mock Zend_Db_Adapter and supply it via config
>> or via `setAdapter`.  The only thing new, to me at least, is the "container"
>> concept, which usually exists as my own final class to wrap my Zend_Db
>> instantiation.
>> --Eric
>> On Jun 4, 2010, at 9:30 AM, drm wrote:
>>
>> On 6/4/2010 12:29 AM, Loïc Frering wrote:
>>
>> Wikipedia: "One benefit of using the dependency injection approach is the
>> reduction of boilerplate code in the application objects since all work to
>> initialize or setup dependencies is handled by a provider component."
>>
>> Symfony's DI container definition is particularly easy and explicit. You
>> should have a look at his documentation, it is quite interesting.
>>
>> My point is that, imo, you should see through the concept of a DI and DI
>> container mechanism (or builder for that matter), and look at the actual
>> design issues that a DI is trying to solve. What you will find out (or at
>> least, what I have gathered) is that is basically a matter of getting
>> everything designed by-contract, and defensive programming. DI then becomes
>> a breeze and you wouldn't need a separate component for it. An
>> object/resource/component-builder is another issue and has in fact nothing
>> to do with DI. That could, in ZF terms, be solved getting Zend_Application's
>> bootstrapping method more "on-demand" and employ more lazy-load and a better
>> unified implementation of the setOptions()-mechanism.
>>
>>
>> drm / Gerard
>>
>>

--
Loïc Frering
[hidden email]