On Wed, Jun 14, 2017 at 3:39 AM, Vitor Medina Cruz
wrote:
> Yes, I can understand that, but I will have to practice more with
> Smalltalk to comprehend better.
>
Keep some notes. When you get to the end and you've had a good soaking in
Smalltalk, it would be good to read of how your thinking a
Yes, I can understand that, but I will have to practice more with
Smalltalk to comprehend better.
Still I think there are some objects used by large bits of the application
that would benefit the design if they have it's creation decoupled and
somehow organized, but I am convinced that a simple s
Consider that in Java, one can /only /achieve polymorphic behavior across
objects by using /interfaces /or /inheritance/. In Smalltalk one can
achieve polymorphic behavior across objects just by *having them understand
the same message*.
The need to have complex schemes for the wiring of objects
>
> I don't think it should. If you have a small cluster of objects where you
> can manage the dependencies yourself, you can compose larger objects from
> them and manage the dependencies the same way. By doing so, you'll get an
> object that is simpler from the outside than it's parts in the insi
In SmallTalk:-
1. Blocks (i.e. anonymous functions) means that one needs not necessarily
implement a /Class/ (MovieFinder), in order to vary alternative behavior,
unlike Java (before 8).
2. If one does want a number of "finders" (as Classes), then one will
typically see one "injected" (constructo
Peter Uhnak wrote
> Scale can make all the difference.
I don't think it should. If you have a small cluster of objects where you
can manage the dependencies yourself, you can compose larger objects from
them and manage the dependencies the same way. By doing so, you'll get an
object that is simp
On Thu, Jun 08, 2017 at 08:02:04AM -0700, Attila Magyar wrote:
> Vitor Medina Cruz wrote
> > This is exactly my concern! Sure, for small stuff that is not a problem,
> > but what if you have a big app?
>
> I don't think it makes any difference.
Scale can make all the difference. Imagine the compl
On Thu, Jun 08, 2017 at 08:46:15AM -0300, Vitor Medina Cruz wrote:
> 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
Vitor Medina Cruz wrote
> This is exactly my concern! Sure, for small stuff that is not a problem,
> but what if you have a big app?
I don't think it makes any difference. You have to decide in each case
whether an object is an internal (implementation detail) and therefore it
must be created from
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
> It seems to be broken.
Here is an archived version. http://archive.li/GCbEY#selection-755.0-755.38
--
View this message in context:
http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4950480.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 everyth
On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar 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'
> I don't see what is special about this. You can easily arrange instance
> creation order with methods on the class-side of your domain classes.
I will not use the term "class", but rather a "service" (service can be just a
single class, but that is not always the case). The point of inversion
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 th
On Tue, Jun 6, 2017 at 9:11 PM, Vitor Medina Cruz
wrote:
> Thanks for the detailed answer ben :)
>
> I will try to clarify a little: the question is how to loosely wire
> objects, such as MovieLister to MovieFinder, so that changes in the wiring
> can be made without effort. In Java, people use D
Thanks for the detailed answer ben :)
I will try to clarify a little: the question is how to loosely wire
objects, such as MovieLister to MovieFinder, so that changes in the wiring
can be made without effort. In Java, people use DI containers and xml files
or annotations to provide the wiring conf
On Tue, Jun 6, 2017 at 5:11 AM, Stephane Ducasse
wrote:
> Tx ben.
> When I see all this complexity for something that looks not that complex:
> I prefer to pass the class and get done.
> May be I missed something obvious... but when I see something too complex
> I start to get worried.
>
> I thin
Tx ben.
When I see all this complexity for something that looks not that complex: I
prefer to pass the class and get done.
May be I missed something obvious... but when I see something too complex I
start to get worried.
I think that thinking about the contract between classes at runtime is
import
On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz
wrote:
> Thanks for the answer Ben and Stephane.
>
> I already read A Mentoring Course on Smalltalk, Valloud, there is nothing
> there I could use in this case :( . I will look after for The Design
> Patterns Smalltalk Companion. Most of the sourc
Thanks for the answer Ben and Stephane.
I already read A Mentoring Course on Smalltalk, Valloud, there is nothing
there I could use in this case :( . I will look after for The Design
Patterns Smalltalk Companion. Most of the sources provided I already know
of or went in the same lines lines of wha
Why don't you simply pass the class and use that class in your MovieLister?
MovieLister new
finderClass: MySuperCoolFinderClass
...
MovieLister finder
finderClass new .
What is wrong with that.
If you do not want to have a reference at runtime to a Finder then you
need to use ann
Sorry I'm not familiar with the pattern, so I don't have a direct answer,
and the following might not have a direct answer either, but in general
I'd strongly suggest
two books for adapting from static OO languages.
1. The Design Patterns Smalltalk Companion, Alpert, Brown & Woolf -
including som
Hello,
I would like to know how people in Pharo ecosystem do to deal with object
wiring, as described by Marting Fowler in
https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection:
"A common issue to deal with is how to wire together different elements:
how do you fit together
24 matches
Mail list logo
