[ZF3] [Debate] Remove ServiceLocatorAwareInterface from AbstractController #5168

Closed
macnibblet opened this Issue Sep 26, 2013 · 90 comments

Comments

Projects
None yet
@macnibblet
Contributor

macnibblet commented Sep 26, 2013

Heya people

After a rather interesting discussion in #5156 many people tend to agree that having the AbstractController implement the ServiceLocatorAwareInterface is a bad idea since it allows for poor practise.

Yes, it can be convenient at times but it's used far too carelessly. Removing the ServiceLocatorAwareInterface we can "enforce" better practise among our users ?

@blanchonvincent

This comment has been minimized.

Show comment Hide comment
@blanchonvincent

blanchonvincent Sep 26, 2013

Contributor

Agree with removing the SM in the controller👍

Contributor

blanchonvincent commented Sep 26, 2013

Agree with removing the SM in the controller👍

@Ocramius

This comment has been minimized.

Show comment Hide comment
@Ocramius

Ocramius Sep 26, 2013

Member

@macnibblet fear the rage of those who do RAD!

I think we still need to keep its "dirty little brother" somewhere...

Member

Ocramius commented Sep 26, 2013

@macnibblet fear the rage of those who do RAD!

I think we still need to keep its "dirty little brother" somewhere...

@macnibblet

This comment has been minimized.

Show comment Hide comment
@macnibblet

macnibblet Sep 26, 2013

Contributor

@Ocramius, so people who do RAD don't write tests ....?

Contributor

macnibblet commented Sep 26, 2013

@Ocramius, so people who do RAD don't write tests ....?

@stefanotorresi

This comment has been minimized.

Show comment Hide comment
@stefanotorresi

stefanotorresi Sep 26, 2013

Contributor

yea, remove it altogether, otherwise I will spam with some more strange ideas! :p

👍 btw

Contributor

stefanotorresi commented Sep 26, 2013

yea, remove it altogether, otherwise I will spam with some more strange ideas! :p

👍 btw

@localheinz

This comment has been minimized.

Show comment Hide comment
@localheinz

localheinz Sep 26, 2013

Member

👍

Member

localheinz commented Sep 26, 2013

👍

@Ocramius

This comment has been minimized.

Show comment Hide comment
@Ocramius

Ocramius Sep 26, 2013

Member

@macnibblet actually, people who do RAD most people don't write tests.

While I fully support this choice (removing ServiceLocatorAwareInterface from wherever possible), this is actually going to be a plus only for the 10% of developers who do testing and apply best practices.

Member

Ocramius commented Sep 26, 2013

@macnibblet actually, people who do RAD most people don't write tests.

While I fully support this choice (removing ServiceLocatorAwareInterface from wherever possible), this is actually going to be a plus only for the 10% of developers who do testing and apply best practices.

@GeeH

This comment has been minimized.

Show comment Hide comment
@GeeH

GeeH Sep 26, 2013

Remove that bad boy, remove it now!

👍

GeeH commented Sep 26, 2013

Remove that bad boy, remove it now!

👍

@Slamdunk

This comment has been minimized.

Show comment Hide comment
@Slamdunk

Slamdunk Sep 26, 2013

Contributor

Remove it.

@Ocramius don't worry about that 90%: the next day ZF3 will go stable, someone will create a Module to subclass AbstractController with ServiceLocatorAwareInterface; if you are fast enough, you can be the one, calling that Module DontUseMe\WriteTestsInstead\Module

Contributor

Slamdunk commented Sep 26, 2013

Remove it.

@Ocramius don't worry about that 90%: the next day ZF3 will go stable, someone will create a Module to subclass AbstractController with ServiceLocatorAwareInterface; if you are fast enough, you can be the one, calling that Module DontUseMe\WriteTestsInstead\Module

@Thinkscape

This comment has been minimized.

Show comment Hide comment
@Thinkscape

Thinkscape Sep 26, 2013

Member

I smell nitpicking here. There are bigger, more general issues with using ServiceManager (or service containers in general), ducks vs interfaces and "magic-injection" based on *AwareInterface... there's also topic of building fast DI engine that would solve other group of issues etc.

Picking apart smaller implementation details from zf2 does not amount the the quality and quantity of discussion we have had when architecting zf2. We had tens of threads, RFC in (RIP) wiki and general architecture discussions there.

I don't like the idea of building zf3 by removing bits and pieces of zf2 and calling that progress. If you want to tackle the problem, let's start real discussion :-)

Member

Thinkscape commented Sep 26, 2013

I smell nitpicking here. There are bigger, more general issues with using ServiceManager (or service containers in general), ducks vs interfaces and "magic-injection" based on *AwareInterface... there's also topic of building fast DI engine that would solve other group of issues etc.

Picking apart smaller implementation details from zf2 does not amount the the quality and quantity of discussion we have had when architecting zf2. We had tens of threads, RFC in (RIP) wiki and general architecture discussions there.

I don't like the idea of building zf3 by removing bits and pieces of zf2 and calling that progress. If you want to tackle the problem, let's start real discussion :-)

@bakura10

This comment has been minimized.

Show comment Hide comment
@bakura10

bakura10 Sep 26, 2013

Contributor

+1 !

As I said in another discussion, we need to have a better ZFTool that does:

  • php create controller Foo --factoy (or --invokable)

that: create controller, create factory with basic code, add the key in controllers key. This way a lot of creating file burden is removed, and we keep the nice architecutre.

Contributor

bakura10 commented Sep 26, 2013

+1 !

As I said in another discussion, we need to have a better ZFTool that does:

  • php create controller Foo --factoy (or --invokable)

that: create controller, create factory with basic code, add the key in controllers key. This way a lot of creating file burden is removed, and we keep the nice architecutre.

@macnibblet

This comment has been minimized.

Show comment Hide comment
@macnibblet

macnibblet Sep 26, 2013

Contributor

@Slamdunk 👍
@Thinkscape: Yes i agree with you

Contributor

macnibblet commented Sep 26, 2013

@Slamdunk 👍
@Thinkscape: Yes i agree with you

@juriansluiman

This comment has been minimized.

Show comment Hide comment
@juriansluiman

juriansluiman Sep 26, 2013

Contributor

I am not sure this goes into the right direction. Yes, "we" here are all good developers, actively contributing to the framework. Understand that the user base of zf2/zf3 is much, much larger than the ppl you know here. The learning curve for zf1 was high, zf2 was considered even more difficult. We shouldn't remove RAD features just to enforce users writing proper code. Eventually, it will just end in less usage of the framework, making the user base smaller, causing all kinds of other problems.

If we consider these topics to enforce proper code, we should actively consider replacing tools to bring back the RAD style of development. You should be able to just point out some dependencies in a config file which are automatically injected. I don't know, but we should not remove the parts that are the easiest to learn by new users. Not everybody is perfect, you know :-)

How I see most programmers use frameworks like zf2: first they create all objects themselves, so all new MyForm; everywhere. Then they start learning the SL and use that to grab the form. Eventually they learn DI and inject all dependencies into the constructor. You seriously cannot teach programmers this third stage if they are not allowed to fail (and learn from that) at stage one or two.

Contributor

juriansluiman commented Sep 26, 2013

I am not sure this goes into the right direction. Yes, "we" here are all good developers, actively contributing to the framework. Understand that the user base of zf2/zf3 is much, much larger than the ppl you know here. The learning curve for zf1 was high, zf2 was considered even more difficult. We shouldn't remove RAD features just to enforce users writing proper code. Eventually, it will just end in less usage of the framework, making the user base smaller, causing all kinds of other problems.

If we consider these topics to enforce proper code, we should actively consider replacing tools to bring back the RAD style of development. You should be able to just point out some dependencies in a config file which are automatically injected. I don't know, but we should not remove the parts that are the easiest to learn by new users. Not everybody is perfect, you know :-)

How I see most programmers use frameworks like zf2: first they create all objects themselves, so all new MyForm; everywhere. Then they start learning the SL and use that to grab the form. Eventually they learn DI and inject all dependencies into the constructor. You seriously cannot teach programmers this third stage if they are not allowed to fail (and learn from that) at stage one or two.

@netiul

This comment has been minimized.

Show comment Hide comment
@netiul

netiul Sep 26, 2013

Contributor

@juriansluiman 👍 Couldn't have said it better :)

Contributor

netiul commented Sep 26, 2013

@juriansluiman 👍 Couldn't have said it better :)

@pauloelr

This comment has been minimized.

Show comment Hide comment
@pauloelr

pauloelr Sep 26, 2013

Contributor

My "Not Especialist Developer" Humild Opnion:

I'm really not design pattern especilist nor consider myself a deep expert of programing, in fact i'm just a developer who tries to increase quality of the code produced along the time, many of the evolution of my code is due the shared knowlodge of some experts like you that are right now discussing things i don't fully understand, but i try, i try the same way i try to contribute with ZF2 code in minor bug fixes or even on documentation upgrades, and i did it, to help of course, but to learn either.

As a "not expert" developer i like when the things are easy untill someone more expert then me tell me that there is a better practice, and explain me why i shoudn't do the way i do.

What i'm trying to say is that many of developers like me use the ServiceLocatorAwareInterface thinking that this is a best practice since a huge framework like ZF2 implements it by default, i think you're doing a really great job keeping the framework easy to use and reducing the learning curve, but i also think you, as experts, need to think greater than that and realize that what you do, the way you implement things is being more than a base code to develepers build their application but also a study place for many ones that like me wanna grow as a developer.

This way i think this discussion is far more bigger then remove or not remove the ServiceLocatorAwareInterface form AbstractController, is a discussion about how you want to be the future of PHP Programing, lets assume you decide to keep the things the way it is, i think you should consider explain in docs why it is the way it is and the other (better) ways to do the things.

The same is valid for the other side, if you decide to remove the ServiceLocatorAwareInterface from AbstractController, if you remove it, and explain why you diid this, and how is the correct way to do things and why, i'm pretty sure the "90% of developers who doesn't make tests" will understand the change and start to create better codes.

But again this is just My "Not Especialist Developer" Humild Opnion, i just felt the need to express the position of medium developers to contrast with the experts opinions, i'm holping it helps.

Contributor

pauloelr commented Sep 26, 2013

My "Not Especialist Developer" Humild Opnion:

I'm really not design pattern especilist nor consider myself a deep expert of programing, in fact i'm just a developer who tries to increase quality of the code produced along the time, many of the evolution of my code is due the shared knowlodge of some experts like you that are right now discussing things i don't fully understand, but i try, i try the same way i try to contribute with ZF2 code in minor bug fixes or even on documentation upgrades, and i did it, to help of course, but to learn either.

As a "not expert" developer i like when the things are easy untill someone more expert then me tell me that there is a better practice, and explain me why i shoudn't do the way i do.

What i'm trying to say is that many of developers like me use the ServiceLocatorAwareInterface thinking that this is a best practice since a huge framework like ZF2 implements it by default, i think you're doing a really great job keeping the framework easy to use and reducing the learning curve, but i also think you, as experts, need to think greater than that and realize that what you do, the way you implement things is being more than a base code to develepers build their application but also a study place for many ones that like me wanna grow as a developer.

This way i think this discussion is far more bigger then remove or not remove the ServiceLocatorAwareInterface form AbstractController, is a discussion about how you want to be the future of PHP Programing, lets assume you decide to keep the things the way it is, i think you should consider explain in docs why it is the way it is and the other (better) ways to do the things.

The same is valid for the other side, if you decide to remove the ServiceLocatorAwareInterface from AbstractController, if you remove it, and explain why you diid this, and how is the correct way to do things and why, i'm pretty sure the "90% of developers who doesn't make tests" will understand the change and start to create better codes.

But again this is just My "Not Especialist Developer" Humild Opnion, i just felt the need to express the position of medium developers to contrast with the experts opinions, i'm holping it helps.

@bakura10

This comment has been minimized.

Show comment Hide comment
@bakura10

bakura10 Sep 26, 2013

Contributor

@pauloelr 👍 Couldn't have said it better :)

Contributor

bakura10 commented Sep 26, 2013

@pauloelr 👍 Couldn't have said it better :)

@localheinz

This comment has been minimized.

Show comment Hide comment
@localheinz

localheinz Sep 26, 2013

Member

"100% of developers think they are in the top 10% of developers."

Member

localheinz commented Sep 26, 2013

"100% of developers think they are in the top 10% of developers."

@unixmen

This comment has been minimized.

Show comment Hide comment
@unixmen

unixmen Sep 26, 2013

i think alternatives will not be complicated :

  1. Replacing ServiceLocatorAwareInterface by ServiceLocatorAwareTrait, 2) not using ServiceLocatorAwareTrait in AbstractController and 3) let people just have to use the adequate trait in their controller (and so the corresponding intializer will work in individual controllers scope )

learning namespaces, SL, EventManager, etc was an important step to learn zf2
using traits for this kind of needs, In my opinion, is accessible for all developpers

as ZF3 is gonna use php5.4 or higher , we should discover/develop better oop practices

unixmen commented Sep 26, 2013

i think alternatives will not be complicated :

  1. Replacing ServiceLocatorAwareInterface by ServiceLocatorAwareTrait, 2) not using ServiceLocatorAwareTrait in AbstractController and 3) let people just have to use the adequate trait in their controller (and so the corresponding intializer will work in individual controllers scope )

learning namespaces, SL, EventManager, etc was an important step to learn zf2
using traits for this kind of needs, In my opinion, is accessible for all developpers

as ZF3 is gonna use php5.4 or higher , we should discover/develop better oop practices

@Ocramius

This comment has been minimized.

Show comment Hide comment
@Ocramius

Ocramius Sep 26, 2013

Member

@unixmen I really love this suggestion! That really changes my PoV on this :O

Member

Ocramius commented Sep 26, 2013

@unixmen I really love this suggestion! That really changes my PoV on this :O

@bakura10

This comment has been minimized.

Show comment Hide comment
@bakura10

bakura10 Sep 26, 2013

Contributor

Interesting suggestion unixmen, but for the initializer to work we still need interfaces. Traits can't implement interfaces, sadly.

Contributor

bakura10 commented Sep 26, 2013

Interesting suggestion unixmen, but for the initializer to work we still need interfaces. Traits can't implement interfaces, sadly.

@unixmen

This comment has been minimized.

Show comment Hide comment
@unixmen

unixmen Sep 26, 2013

@Ocramius @bakura10 get used traits used in controller with class_uses() and test existing ServiceLocatorAwareTrait key to inject SL in the controller

http://php.net/manual/en/function.class-uses.php

unixmen commented Sep 26, 2013

@Ocramius @bakura10 get used traits used in controller with class_uses() and test existing ServiceLocatorAwareTrait key to inject SL in the controller

http://php.net/manual/en/function.class-uses.php

@unixmen

This comment has been minimized.

Show comment Hide comment
@unixmen

unixmen Sep 26, 2013

i understand the problem, the initializers process will need to be refactored

(i don't master yet PHP5.4) , i imagine a kind of initializer doing injections in a simple way like this :

if ( array_key_exists('ServiceLocatorAwareTrait' , class_uses($controllerName) )
// or class_uses($controllerName)['ServiceLocatorAwareTrait'] ...
{
$controllerName->setServiceLocator($sl)
}

unixmen commented Sep 26, 2013

i understand the problem, the initializers process will need to be refactored

(i don't master yet PHP5.4) , i imagine a kind of initializer doing injections in a simple way like this :

if ( array_key_exists('ServiceLocatorAwareTrait' , class_uses($controllerName) )
// or class_uses($controllerName)['ServiceLocatorAwareTrait'] ...
{
$controllerName->setServiceLocator($sl)
}

@texdc

This comment has been minimized.

Show comment Hide comment
@texdc

texdc Sep 26, 2013

Contributor

I support the move to traits, but not at the expense of interfaces. They add clarity to code. Be explicit!

Contributor

texdc commented Sep 26, 2013

I support the move to traits, but not at the expense of interfaces. They add clarity to code. Be explicit!

@unixmen

This comment has been minimized.

Show comment Hide comment
@unixmen

unixmen Sep 27, 2013

i realize it can't be easily done like hoped,

i know there are lazy (and bad) ways to use SL via traits but i'm allergic to provide solutions like to use static ServiceLocator ( also static SL with traits is doesn't make sense )

what do you think to remove the ServiceLocatorAwareInterface from AbstractController and as most users use AbstractActionController, using the ServiceLocatorAwareInterface there as a step will improve implementing own's controllers for all reasons we know

unixmen commented Sep 27, 2013

i realize it can't be easily done like hoped,

i know there are lazy (and bad) ways to use SL via traits but i'm allergic to provide solutions like to use static ServiceLocator ( also static SL with traits is doesn't make sense )

what do you think to remove the ServiceLocatorAwareInterface from AbstractController and as most users use AbstractActionController, using the ServiceLocatorAwareInterface there as a step will improve implementing own's controllers for all reasons we know

@Thinkscape

This comment has been minimized.

Show comment Hide comment
@Thinkscape

Thinkscape Sep 27, 2013

Member

@texdc is right.

Sorry to be the one bursting your bubble.

After working with traits (in php) for some time now, I've learned that traits are quite useless for api's - they are "invisible" to the parser, you cannot hint on them, they do not support inheritance, they have fixed subclass/trait calling-tree , they are sketchy when used together with interfaces.

The only way to build framework code consuming interfaces is to use in_array('...', class_uses()) or reflection, which is basically duck typing and does not differ from is_callable([$this, 'setServiceLocator']) ... I fear that jumping on traits will result in us becoming DuckFramework 3 :P

Member

Thinkscape commented Sep 27, 2013

@texdc is right.

Sorry to be the one bursting your bubble.

After working with traits (in php) for some time now, I've learned that traits are quite useless for api's - they are "invisible" to the parser, you cannot hint on them, they do not support inheritance, they have fixed subclass/trait calling-tree , they are sketchy when used together with interfaces.

The only way to build framework code consuming interfaces is to use in_array('...', class_uses()) or reflection, which is basically duck typing and does not differ from is_callable([$this, 'setServiceLocator']) ... I fear that jumping on traits will result in us becoming DuckFramework 3 :P

@macnibblet

This comment has been minimized.

Show comment Hide comment
@macnibblet

macnibblet Sep 27, 2013

Contributor

Why don't we simply move the it to a plugin ? it would actually coherce a lot better with the rest of the controller code

Contributor

macnibblet commented Sep 27, 2013

Why don't we simply move the it to a plugin ? it would actually coherce a lot better with the rest of the controller code

@glen-84

This comment has been minimized.

Show comment Hide comment
@glen-84

glen-84 Sep 27, 2013

Contributor

Not until you rewrite ZF-Commons/ZfcUser (for example), to show how you're supposed to work with controllers that have more than 1 or 2 dependencies (and dependencies that may or may not be used).

Contributor

glen-84 commented Sep 27, 2013

Not until you rewrite ZF-Commons/ZfcUser (for example), to show how you're supposed to work with controllers that have more than 1 or 2 dependencies (and dependencies that may or may not be used).

@froschdesign

This comment has been minimized.

Show comment Hide comment
@froschdesign

froschdesign Sep 27, 2013

Member

@glen-84
I'm on your side, but the reference guide is the correct and the official place for this.

Member

froschdesign commented Sep 27, 2013

@glen-84
I'm on your side, but the reference guide is the correct and the official place for this.

@GeeH

This comment has been minimized.

Show comment Hide comment
@GeeH

GeeH Sep 27, 2013

I don't understand why there's discussion. It's an anti-pattern and should be removed, leaving it in is tantamount to endorsement of the pattern. The Service Locator will still support coding "aware" interfaces, so it can be added back in if it means that much to an individual shitty developer.

GeeH commented Sep 27, 2013

I don't understand why there's discussion. It's an anti-pattern and should be removed, leaving it in is tantamount to endorsement of the pattern. The Service Locator will still support coding "aware" interfaces, so it can be added back in if it means that much to an individual shitty developer.

@macnibblet

This comment has been minimized.

Show comment Hide comment
@macnibblet

macnibblet Sep 27, 2013

Contributor

@spabby, didn't you just learn to write test recently ? :trollface:

Contributor

macnibblet commented Sep 27, 2013

@spabby, didn't you just learn to write test recently ? :trollface:

@GeeH

This comment has been minimized.

Show comment Hide comment
@GeeH

GeeH Sep 27, 2013

💥

Testing is irrelevant, the pattern is a poor one and to endorse it is wrong.

GeeH commented Sep 27, 2013

💥

Testing is irrelevant, the pattern is a poor one and to endorse it is wrong.

@pdobrigkeit

This comment has been minimized.

Show comment Hide comment
@pdobrigkeit

pdobrigkeit Sep 27, 2013

Contributor

If the pattern is poor, then why have a ServiceLocatorAwareInterface at all. Removing from the AbstractController would not solve anything, because the "individual shitty developers" would just add it back to each of their controllers or add another MyOwnAbstractController, which implements the interface. If you want to educate developers we need better resources and make it easier to inject services inside a controller or any other service.

If I would do it the right way, I would need to edit the following files to enable a new Controller:
module.config.php => add route configuration
Module.php => add ControllerFactory
Implement ControllerFactory, which does all the service injection
Implement the actual Controller

This is a pain. For quick an dirty "I need to try something new and just want to have some kind of service and try if stuff works" It is way to much hazzle.

Also for testing maybe someone can explain to me what the difference between mocking the different service objects and mocking a serviceLocator which supplies multiple (mock)objects?

Contributor

pdobrigkeit commented Sep 27, 2013

If the pattern is poor, then why have a ServiceLocatorAwareInterface at all. Removing from the AbstractController would not solve anything, because the "individual shitty developers" would just add it back to each of their controllers or add another MyOwnAbstractController, which implements the interface. If you want to educate developers we need better resources and make it easier to inject services inside a controller or any other service.

If I would do it the right way, I would need to edit the following files to enable a new Controller:
module.config.php => add route configuration
Module.php => add ControllerFactory
Implement ControllerFactory, which does all the service injection
Implement the actual Controller

This is a pain. For quick an dirty "I need to try something new and just want to have some kind of service and try if stuff works" It is way to much hazzle.

Also for testing maybe someone can explain to me what the difference between mocking the different service objects and mocking a serviceLocator which supplies multiple (mock)objects?

@pdobrigkeit

This comment has been minimized.

Show comment Hide comment
@pdobrigkeit

pdobrigkeit Sep 27, 2013

Contributor

How about we could achieve something like this (Pseudo-Code)

class ServiceManager {
    public function getProxy($name) {
        if(!$this->has($name)) {
            throw \Exception('Unknown service');
        }

        $self = $this;

        return function() use ($self, $name) {
            return $self->get($name);
        };

    }
}


class MyServiceFactory {
    public function createService($sl) {
        $myService = new MyService();

        $myService->setSomeLazyService($sl->getProxy('somelazyservice'));
    }
}


class MyService {

    protected $someLazyService;

    public function setSomeLazyService($someLazyService) {
        $this->someLazyService = $someLazyService;
    }

    public function getSomeLazyService() {
        if(is_callable($this->someLazyService)) {
            $someLazyServiceProxy = $this->someLazyService;
            $this->someLazyService = $someLazyServiceProxy();
        }

        return $this->someLazyService;
    }
}
Contributor

pdobrigkeit commented Sep 27, 2013

How about we could achieve something like this (Pseudo-Code)

class ServiceManager {
    public function getProxy($name) {
        if(!$this->has($name)) {
            throw \Exception('Unknown service');
        }

        $self = $this;

        return function() use ($self, $name) {
            return $self->get($name);
        };

    }
}


class MyServiceFactory {
    public function createService($sl) {
        $myService = new MyService();

        $myService->setSomeLazyService($sl->getProxy('somelazyservice'));
    }
}


class MyService {

    protected $someLazyService;

    public function setSomeLazyService($someLazyService) {
        $this->someLazyService = $someLazyService;
    }

    public function getSomeLazyService() {
        if(is_callable($this->someLazyService)) {
            $someLazyServiceProxy = $this->someLazyService;
            $this->someLazyService = $someLazyServiceProxy();
        }

        return $this->someLazyService;
    }
}
@samsonasik

This comment has been minimized.

Show comment Hide comment
@samsonasik

samsonasik Sep 30, 2013

Contributor

Hey, I am one of the shitty developers :p. if it removed, who that propose it should make effort to update the docs so user can easy to adapt :). We can't just say "hey, it should be removed", and leave...

@spabby open source need effort :). you promise to me to "review" my PR to your Spabby/zf2-documentation looooooong time ago, and you keep saying "tomorrow, I will review it" :). And I realized that you delete your branch where I propose my PR :p. 

Contributor

samsonasik commented Sep 30, 2013

Hey, I am one of the shitty developers :p. if it removed, who that propose it should make effort to update the docs so user can easy to adapt :). We can't just say "hey, it should be removed", and leave...

@spabby open source need effort :). you promise to me to "review" my PR to your Spabby/zf2-documentation looooooong time ago, and you keep saying "tomorrow, I will review it" :). And I realized that you delete your branch where I propose my PR :p. 

@GeeH

This comment has been minimized.

Show comment Hide comment
@GeeH

GeeH Sep 30, 2013

Apologies Abdul, you will have submitted PR to the wrong place if I deleted
the branch.

Let's be clear what is proposed here. This is a proposal for ZF 3.0, NOT a
proposal for the 2.x branch. The documentation will be re-written for the
3.0 release anyway, and this is not a valid reason not to make breaking
changes. What isn't up for debate is wether there will be breaking changes
in 3.0 (there will), so please keep this on topic and discuss wether THIS
breaking change would be appropriate for the framework.

With regards to my "shitty developers" comment, please ignore it, it was a
tongue in cheek remark that I shouldn't have posted on this list as not
everyone knows my personality - apologies if I offended anyone by saying
that, it was meant as a joke.

@philipp - "If the pattern is poor, then why have a
ServiceLocatorAwareInterface at all." I heartily agree, I wouldn't have the
interface at all (or the trait if that's the way 3.0 goes). The Service
Locator was never designed to be passed around individual classes.

Gary

On Mon, Sep 30, 2013 at 7:33 AM, Abdul Malik Ikhsan <
notifications@github.com> wrote:

Hey, I am one of the shitty developers :p. if it removed, who that propose
it should make effort to update the docs so user can easy to adapt :). We
can't just say "hey, it should be removed", and leave...

@spabby https://github.com/Spabby open source need effort :). you
promise to me to "review" my PR to your Spabby/zf2-documentation looooooong
time ago, and you keep saying "tomorrow, I will review it" :). And I
realized that you delete your branch where I propose my PR :p.


Reply to this email directly or view it on GitHubhttps://github.com/zendframework/zf2/issues/5168#issuecomment-25339996
.

GeeH commented Sep 30, 2013

Apologies Abdul, you will have submitted PR to the wrong place if I deleted
the branch.

Let's be clear what is proposed here. This is a proposal for ZF 3.0, NOT a
proposal for the 2.x branch. The documentation will be re-written for the
3.0 release anyway, and this is not a valid reason not to make breaking
changes. What isn't up for debate is wether there will be breaking changes
in 3.0 (there will), so please keep this on topic and discuss wether THIS
breaking change would be appropriate for the framework.

With regards to my "shitty developers" comment, please ignore it, it was a
tongue in cheek remark that I shouldn't have posted on this list as not
everyone knows my personality - apologies if I offended anyone by saying
that, it was meant as a joke.

@philipp - "If the pattern is poor, then why have a
ServiceLocatorAwareInterface at all." I heartily agree, I wouldn't have the
interface at all (or the trait if that's the way 3.0 goes). The Service
Locator was never designed to be passed around individual classes.

Gary

On Mon, Sep 30, 2013 at 7:33 AM, Abdul Malik Ikhsan <
notifications@github.com> wrote:

Hey, I am one of the shitty developers :p. if it removed, who that propose
it should make effort to update the docs so user can easy to adapt :). We
can't just say "hey, it should be removed", and leave...

@spabby https://github.com/Spabby open source need effort :). you
promise to me to "review" my PR to your Spabby/zf2-documentation looooooong
time ago, and you keep saying "tomorrow, I will review it" :). And I
realized that you delete your branch where I propose my PR :p.


Reply to this email directly or view it on GitHubhttps://github.com/zendframework/zf2/issues/5168#issuecomment-25339996
.

@samsonasik

This comment has been minimized.

Show comment Hide comment
@samsonasik

samsonasik Sep 30, 2013

Contributor

@spabby you are the one that suggest me to submit the PR to that branch :p . ah, ok, it's out of topic. but my underline is if we proposed to delete some functionality ( ZF3, ZF4, or whatever ), we need to keep in mind that we need to take balance with the docs :)

Contributor

samsonasik commented Sep 30, 2013

@spabby you are the one that suggest me to submit the PR to that branch :p . ah, ok, it's out of topic. but my underline is if we proposed to delete some functionality ( ZF3, ZF4, or whatever ), we need to keep in mind that we need to take balance with the docs :)

@froschdesign

This comment has been minimized.

Show comment Hide comment
@froschdesign

froschdesign Sep 30, 2013

Member
Member

froschdesign commented Sep 30, 2013

@tgarbiak

This comment has been minimized.

Show comment Hide comment
@tgarbiak

tgarbiak Oct 1, 2013

Remove it please, along with:
a) providing the tools to facilitate rapid creation of factories (what @bakura10 said)
b) do other improvements toward proper usage of DI
e.g. no more: if (!$this->eventManager) $this->eventManager = new EventManager();, more careful use of traits in general, proper DI in other ZF libraries (Zend\Crypt is probably the main offender), etc.

For those who ask why. Because non-implicit dependencies are not maintainable and in no time RAD becomes SAD (as both slow and also sad).

tgarbiak commented Oct 1, 2013

Remove it please, along with:
a) providing the tools to facilitate rapid creation of factories (what @bakura10 said)
b) do other improvements toward proper usage of DI
e.g. no more: if (!$this->eventManager) $this->eventManager = new EventManager();, more careful use of traits in general, proper DI in other ZF libraries (Zend\Crypt is probably the main offender), etc.

For those who ask why. Because non-implicit dependencies are not maintainable and in no time RAD becomes SAD (as both slow and also sad).

@macnibblet

This comment has been minimized.

Show comment Hide comment
@macnibblet

macnibblet Oct 1, 2013

Contributor

I wrote a little blog post for those that are interested http://macnibblet.blogspot.se/2013/10/why-i-wish-to-remove-getservicelocator.html

Contributor

macnibblet commented Oct 1, 2013

I wrote a little blog post for those that are interested http://macnibblet.blogspot.se/2013/10/why-i-wish-to-remove-getservicelocator.html

@glen-84

This comment has been minimized.

Show comment Hide comment
@glen-84

glen-84 Oct 4, 2013

Contributor

@froschdesign

http://framework.zend.com/manual/2.2/en/user-guide/database-and-models.html

... uses the SL as well.

My point is, one can't say that it's an anti-pattern and used by shitty developers when you're essentially teaching developers (at least new ones) to use these patterns. If it's such a bad practice, then the official reference guide should show how it should be done (and not just with a hello-world application).

A good example is a user controller. If it needs a registration form, a login form, maybe an activation form, etc. plus at least 1 service, passing this all in via the constructor is retarded, which means you have to break it into individual controllers (LoginController, RegistrationController, etc.), which (at least for me), is difficult to get used to at first.

Contributor

glen-84 commented Oct 4, 2013

@froschdesign

http://framework.zend.com/manual/2.2/en/user-guide/database-and-models.html

... uses the SL as well.

My point is, one can't say that it's an anti-pattern and used by shitty developers when you're essentially teaching developers (at least new ones) to use these patterns. If it's such a bad practice, then the official reference guide should show how it should be done (and not just with a hello-world application).

A good example is a user controller. If it needs a registration form, a login form, maybe an activation form, etc. plus at least 1 service, passing this all in via the constructor is retarded, which means you have to break it into individual controllers (LoginController, RegistrationController, etc.), which (at least for me), is difficult to get used to at first.

@GeeH

This comment has been minimized.

Show comment Hide comment
@GeeH

GeeH Oct 4, 2013

I heartily disagree; I don't get forms from the service locator anyway, as they have no dependencies. Forms can be instanced in the relevant action as they have always done.

I would agree the user guide needs updating to remove the lazy loading of the service via the ServiceManager. I know that @akrabat who wrote the tutorial believes that while having the service locator in the controller is an anti-pattern, it's convenience stops people from creating one controller per action which he believes is wrong. I've pinged him so I'll let him clarify if he feels the need to. (I disagree btw)

Again, to re-iterate, I don't believe that "the docs will need to be updated" is a valid reason not to make any breaking change.

GeeH commented Oct 4, 2013

I heartily disagree; I don't get forms from the service locator anyway, as they have no dependencies. Forms can be instanced in the relevant action as they have always done.

I would agree the user guide needs updating to remove the lazy loading of the service via the ServiceManager. I know that @akrabat who wrote the tutorial believes that while having the service locator in the controller is an anti-pattern, it's convenience stops people from creating one controller per action which he believes is wrong. I've pinged him so I'll let him clarify if he feels the need to. (I disagree btw)

Again, to re-iterate, I don't believe that "the docs will need to be updated" is a valid reason not to make any breaking change.

@macnibblet

This comment has been minimized.

Show comment Hide comment
@macnibblet

macnibblet Oct 4, 2013

Contributor

Decision making time

So now then i feel everyone has had time to throw a rant at this discussion i want to propose a poll.
From here on out i want a 👍 or 👎 and if you really need to a short comment.

The proposed solution would be the following.

1, We remove the interface on the controller
2, We provide a trait that would allow for the functionality to exist

Optional
We provide a RAD version of ZendSkeletonApplication with this stuff enabled by default, recommending this to beginners or RAD people. With a length post about why using it is a bad idea.

I can write that lengthy post.

NOT MORE DISCUSSIONS ABOUT DOCUMENTATION!

Contributor

macnibblet commented Oct 4, 2013

Decision making time

So now then i feel everyone has had time to throw a rant at this discussion i want to propose a poll.
From here on out i want a 👍 or 👎 and if you really need to a short comment.

The proposed solution would be the following.

1, We remove the interface on the controller
2, We provide a trait that would allow for the functionality to exist

Optional
We provide a RAD version of ZendSkeletonApplication with this stuff enabled by default, recommending this to beginners or RAD people. With a length post about why using it is a bad idea.

I can write that lengthy post.

NOT MORE DISCUSSIONS ABOUT DOCUMENTATION!

@stefanotorresi

This comment has been minimized.

Show comment Hide comment
@stefanotorresi

stefanotorresi Oct 4, 2013

Contributor

👍

Contributor

stefanotorresi commented Oct 4, 2013

👍

@Hotas2k4

This comment has been minimized.

Show comment Hide comment
@Hotas2k4

Hotas2k4 Oct 4, 2013

👍

Hotas2k4 commented Oct 4, 2013

👍

@tgarbiak

This comment has been minimized.

Show comment Hide comment
@tgarbiak

tgarbiak Oct 4, 2013

👍

tgarbiak commented Oct 4, 2013

👍

@DASPRiD

This comment has been minimized.

Show comment Hide comment
@DASPRiD

DASPRiD Oct 4, 2013

Member

👍

Member

DASPRiD commented Oct 4, 2013

👍

@froschdesign

This comment has been minimized.

Show comment Hide comment
@froschdesign

froschdesign Oct 4, 2013

Member

👍

Member

froschdesign commented Oct 4, 2013

👍

@bakura10

This comment has been minimized.

Show comment Hide comment
@bakura10

bakura10 Oct 4, 2013

Contributor

👍

Contributor

bakura10 commented Oct 4, 2013

👍

@shipleyr

This comment has been minimized.

Show comment Hide comment
@shipleyr

shipleyr Oct 4, 2013

Contributor

👍

Contributor

shipleyr commented Oct 4, 2013

👍

@Ocramius

This comment has been minimized.

Show comment Hide comment
@Ocramius

Ocramius Oct 4, 2013

Member

👍

Member

Ocramius commented Oct 4, 2013

👍

@Maks3w

This comment has been minimized.

Show comment Hide comment
@Maks3w

Maks3w Oct 4, 2013

Member

👍 With RAD version for beginners.

Member

Maks3w commented Oct 4, 2013

👍 With RAD version for beginners.

@samsonasik

This comment has been minimized.

Show comment Hide comment
@samsonasik

samsonasik Oct 4, 2013

Contributor

👍 as far as there are guaranteed resources for beginners / new users.

Contributor

samsonasik commented Oct 4, 2013

👍 as far as there are guaranteed resources for beginners / new users.

@texdc

This comment has been minimized.

Show comment Hide comment
@texdc

texdc Oct 4, 2013

Contributor

👍 SoC

Contributor

texdc commented Oct 4, 2013

👍 SoC

@pauloelr

This comment has been minimized.

Show comment Hide comment
@pauloelr

pauloelr Oct 4, 2013

Contributor

👍

Contributor

pauloelr commented Oct 4, 2013

👍

@glen-84

This comment has been minimized.

Show comment Hide comment
@glen-84

glen-84 Oct 4, 2013

Contributor

👍 ... if the skeleton application will be updated at the same time.

Contributor

glen-84 commented Oct 4, 2013

👍 ... if the skeleton application will be updated at the same time.

@unixmen

This comment has been minimized.

Show comment Hide comment
@unixmen

unixmen Oct 5, 2013

👍

maybe a base skeleton + a modules for that purpose (or some config that can be disabled )

(using many skeleton apps could be another possible slackness )

unixmen commented Oct 5, 2013

👍

maybe a base skeleton + a modules for that purpose (or some config that can be disabled )

(using many skeleton apps could be another possible slackness )

@EvanDotPro

This comment has been minimized.

Show comment Hide comment
@EvanDotPro

EvanDotPro Oct 17, 2013

Member

👍 better late than never.

Member

EvanDotPro commented Oct 17, 2013

👍 better late than never.

@Amazium

This comment has been minimized.

Show comment Hide comment
@Amazium

Amazium Oct 17, 2013

👍

Amazium commented Oct 17, 2013

👍

@danizord

This comment has been minimized.

Show comment Hide comment
@danizord

danizord Oct 17, 2013

Contributor

I'm 👍 with remove the ServiceLocatorAwareInterface, trait, initializer and all about it.

@macnibblet I like your idea of ​​a controller plugin. This will keep the ease and quickness for who want it, but without sacrificing the performance of those who want to do it the right way.

public function fooAction() {
    $service = $this->services()->get('MyService');
}

Thoughts?

Contributor

danizord commented Oct 17, 2013

I'm 👍 with remove the ServiceLocatorAwareInterface, trait, initializer and all about it.

@macnibblet I like your idea of ​​a controller plugin. This will keep the ease and quickness for who want it, but without sacrificing the performance of those who want to do it the right way.

public function fooAction() {
    $service = $this->services()->get('MyService');
}

Thoughts?

@markdrake

This comment has been minimized.

Show comment Hide comment
@markdrake

markdrake Oct 17, 2013

👍

👍

@rodsouto

This comment has been minimized.

Show comment Hide comment
@rodsouto

rodsouto Oct 17, 2013

@danizord the anti-pattern is still present, a controller shouldn't have access to the SM in any way :)

👍

@danizord the anti-pattern is still present, a controller shouldn't have access to the SM in any way :)

👍

@HardieBoeve

This comment has been minimized.

Show comment Hide comment
@HardieBoeve

HardieBoeve Oct 17, 2013

👍

👍

@Amazium

This comment has been minimized.

Show comment Hide comment
@Amazium

Amazium Oct 17, 2013

@danizord the idea is that you don't use it in the controller at all. Not injected, but not as plugin either. You should inject classes you pull out of the SM into the controller, not let the controller do the pulling.

Amazium commented Oct 17, 2013

@danizord the idea is that you don't use it in the controller at all. Not injected, but not as plugin either. You should inject classes you pull out of the SM into the controller, not let the controller do the pulling.

@danizord

This comment has been minimized.

Show comment Hide comment
@danizord

danizord Oct 17, 2013

Contributor

@rodsouto and @Amazium Yes, I know the best practice! I'm just suggesting to create only a plugin istead of:

  • Create a ServiceAwareTrait, but don't use it in AbstractController
  • Create an initializer for the trait but don't register it.
  • Create another SkeletonApp for people who want to use the anti-pattern.
Contributor

danizord commented Oct 17, 2013

@rodsouto and @Amazium Yes, I know the best practice! I'm just suggesting to create only a plugin istead of:

  • Create a ServiceAwareTrait, but don't use it in AbstractController
  • Create an initializer for the trait but don't register it.
  • Create another SkeletonApp for people who want to use the anti-pattern.
@stefanotorresi

This comment has been minimized.

Show comment Hide comment
@stefanotorresi

stefanotorresi Oct 17, 2013

Contributor

@danizord
this has already been established since this comment

Contributor

stefanotorresi commented Oct 17, 2013

@danizord
this has already been established since this comment

@danizord

This comment has been minimized.

Show comment Hide comment
@danizord

danizord Oct 17, 2013

Contributor

@stefanotorresi 😱 I'm suggesting quite the opposite. I suggested creating only the plugin instead of it all.

Contributor

danizord commented Oct 17, 2013

@stefanotorresi 😱 I'm suggesting quite the opposite. I suggested creating only the plugin instead of it all.

@stefanotorresi

This comment has been minimized.

Show comment Hide comment
@stefanotorresi

stefanotorresi Oct 17, 2013

Contributor

@danizord yes, I get it, but a plugin would probably be 'too easy' and wouldn't be enough of a clear message against the whole practice. The point of what has been discussed so far is that the current pattern should be kept feasible while being blatantly discouraged. This way, at some point in the future it could be even get ridden of completely.

Contributor

stefanotorresi commented Oct 17, 2013

@danizord yes, I get it, but a plugin would probably be 'too easy' and wouldn't be enough of a clear message against the whole practice. The point of what has been discussed so far is that the current pattern should be kept feasible while being blatantly discouraged. This way, at some point in the future it could be even get ridden of completely.

@glen-84

This comment has been minimized.

Show comment Hide comment
@glen-84

glen-84 Oct 20, 2013

Contributor

I've posted a question about dependency management on Stack Overflow here. It would be great to get some insight from the experienced ZF developers in this thread WRT how you handle dependencies in your own applications.

Contributor

glen-84 commented Oct 20, 2013

I've posted a question about dependency management on Stack Overflow here. It would be great to get some insight from the experienced ZF developers in this thread WRT how you handle dependencies in your own applications.

@bacinsky

This comment has been minimized.

Show comment Hide comment
@bacinsky

bacinsky Nov 4, 2013

Contributor

I think this is not a good idea. I use a serviceLocator for RAD prototyping, and when it's appropriate I redesign to injections. This saves me a lot of trial and error time than playing with configs etc. The whole PHP is about to be able to write a quick dirty code. Instead of forcing devs to write time consuming clean testable code, write a better documentation to explain some bad practice when is bad, because it's not as bad always. There should be always some space for a choice.

Contributor

bacinsky commented Nov 4, 2013

I think this is not a good idea. I use a serviceLocator for RAD prototyping, and when it's appropriate I redesign to injections. This saves me a lot of trial and error time than playing with configs etc. The whole PHP is about to be able to write a quick dirty code. Instead of forcing devs to write time consuming clean testable code, write a better documentation to explain some bad practice when is bad, because it's not as bad always. There should be always some space for a choice.

@DASPRiD

This comment has been minimized.

Show comment Hide comment
@DASPRiD

DASPRiD Nov 5, 2013

Member

@bacinsky The choice is always there, just use the interface and the trait.

Member

DASPRiD commented Nov 5, 2013

@bacinsky The choice is always there, just use the interface and the trait.

@bacinsky

This comment has been minimized.

Show comment Hide comment
@bacinsky

bacinsky Nov 5, 2013

Contributor

@DASPRiD I'm fine with that. That's clean.
👍

Contributor

bacinsky commented Nov 5, 2013

@DASPRiD I'm fine with that. That's clean.
👍

@agustincl

This comment has been minimized.

Show comment Hide comment
@agustincl

agustincl Nov 25, 2013

cool

cool

@localheinz

This comment has been minimized.

Show comment Hide comment
@localheinz

localheinz Jul 13, 2014

Member

@macnibblet

I think you should fix the title of this issue:

  • [ ZF3 ] vs [ZF3]
  • [ Debate] vs [Debate]
Member

localheinz commented Jul 13, 2014

@macnibblet

I think you should fix the title of this issue:

  • [ ZF3 ] vs [ZF3]
  • [ Debate] vs [Debate]

@macnibblet macnibblet changed the title from [ ZF3 ] [ Debate] Remove ServiceLocatorAwareInterface from AbstractController to [ZF3] [Debate] Remove ServiceLocatorAwareInterface from AbstractController Jul 13, 2014

@RalfEggert

This comment has been minimized.

Show comment Hide comment
@RalfEggert

RalfEggert Jul 14, 2014

Contributor

@macnibblet

And maybe the milestone could be set to 3.0.0 as well? makes it easier to find the issue.

Contributor

RalfEggert commented Jul 14, 2014

@macnibblet

And maybe the milestone could be set to 3.0.0 as well? makes it easier to find the issue.

@Ocramius Ocramius added this to the 3.0.0 milestone Jul 14, 2014

@Ocramius

This comment has been minimized.

Show comment Hide comment
@Ocramius

Ocramius Jul 14, 2014

Member

done

Member

Ocramius commented Jul 14, 2014

done

@Maks3w

This comment has been minimized.

Show comment Hide comment
@Maks3w

Maks3w Oct 9, 2015

Member

Those interfaces not longer exists on SM v3

Member

Maks3w commented Oct 9, 2015

Those interfaces not longer exists on SM v3

@Maks3w Maks3w closed this Oct 9, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment