Also realize the Smalltalk image is a container... No need for fancy XML externalization because you can do that with code.
I have an app where I wire all kinds of things together in a configuration file which is Smalltalk code and I just compile a method like "wireEverything" that as source has that configuration file. Or just do a Compiler evaluate: aLongConfigurationStringInSmalltalk Any Dictionary can be a "SpringContext" thing. Now decorators with specific features like transaction support etc is not something we have and things like Spring do have. We could take inspiration from Spring Boot. https://projects.spring.io/spring-boot/ Best Regards, Phil On Thu, Jun 8, 2017 at 1:46 PM, Vitor Medina Cruz <vitormc...@gmail.com> wrote: > Thanks for the links Attila, do you have an alternative one to the > http://higherorderlogic.com/2011/07/is-dependency-injection-like-facebook? > It seems to be broken. > > I also started to also think containers don't worth the effort, but I am > still concerned with problems faced with hand wiring everything as Peter > clearly exemplified, thanks for the excellent summary and exemplification > Peter! > > And this is just a basic example. Imagine that the PeopleService also >> needs other services for it's use, and those services need more services, >> and you want to keep everything separated as much as possible... >> instantiation by hand will simply not cut it > > > This is exactly my concern! Sure, for small stuff that is not a problem, > but what if you have a big app? Now, my experience with containers and Java > may be shadowing my vision: people in Java community tend to use anemic > model and to create gazzilions layers for even simple stuff, which make the > wiring problem even worse. My experiments with a more OO approach and > Smalltalk tells me one would need much less need of containers by using > proper OO and a less verbose language, but I am not sure. > > Keep in mind however that relates primarily to using application >> frameworks, where the framework mandates the control, and the framework is >> the one calling you, and therefore it will also provide you with necessary >> parts. After all you are not even creating PeopleService class, the >> framework instantiates it for you and gives it to another services/classes >> that needed it. > > > This is true for IoC DI containers, but I don't think it applies for > service locator, which, I think, could not be considered a framework > approach. Actually, I think being a framework is the big problem of the of > the former, since when I start to use an IoC container to create objects I > got tied to it in a very basic and pervasive operation of an OO system: > object creation. Suddenly everything must be created through the DI > container, but that is not true for Service Locator. > > However I wouldn't be surprised if the liveness of Smalltalk/Pharo >> environment eliminated some of the problems that DI is trying to solve. > > > That is precisely what I wanted to know. It seems there are no DI > counterpart in the Pharo/Smalltalk environment, ok, so what people do to to > deal with the above mentioned problem? Hand wiring is suffice? Is there > anything in the liveness of Smalltalk/Pharo that eliminates the need for > it? People use simple Service Locator, or variations of it? > > > cheers! > Vitor > > On Wed, Jun 7, 2017 at 9:32 PM, Ben Coman <b...@openinworld.com> wrote: > >> >> >> On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar <m.magy...@gmail.com> >> wrote: >> >>> I don't think using a DI container worth the effort. They add lots of >>> complexities and solve very little. For some reason DI containers became >>> very popular in the Java world, but if you take a look at other >>> programming >>> communities you'll realize that many people are perfectly happy without >>> using these containers. Using DI and using a DI container is orthogonal. >>> As >>> you also said you can just pass dependencies to objects to achieve loose >>> coupling. Yes, you have to do this manually but what's the big deal? >>> We're >>> talking about code with cyclomatic complexity of 1. Calling a >>> constructor is >>> not a problem that need to be solved. Using an external XML >>> configuration to >>> describe object wiring is the worst idea ever. >>> >>> Here is an article about using plain old object composition to do DI >>> >>> http://blog.davidpeterson.co.uk/2011/01/object-oriented-example.html >>> >>> Some more thoughts about the problems associated with DI containers: >>> >>> http://www.natpryce.com/articles/000783.html >> >> >> I liked this... "the [Dependency Injection] pattern also used to be >> called "third-party binding" or "third-party connect": some third party is >> responsible for connecting an object satisfying the service requirements of >> a component" >> This makes the subject seem less esoteric. It reminds me of hearing that >> the first (secret) task when doing a PhD is to invent new terms for common >> ones, and base your writings on that. Perhaps its the same for consultants >> and framework developers. ;P Or maybe everything seems esoteric until you >> have experience with it and I've not done much with Java, certainly not big >> applications. >> >> Thx Peter for your example and how you prior experience compares to >> Pharo. >> >> cheers -ben >> >> >>> http://higherorderlogic.com/2011/07/is-dependency-injection- >>> like-facebook >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Wiring-o >>> bjects-IoC-and-Service-Locator-tp4949280p4949720.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >> >
