June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Peter Uhnak

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 complexity of connecting N elements. If you have just tree objects/classes/systems... you need just two connections, but you if double the number of elements, you need more than seven times more connections (to form a complete graph). Of course in practice that number will be smaller, but certainly more than linear to the number of elements. So what works in small scale doesn't necessarily translate to bigger scale, not to mention that brand new concerns are probably going to arise... just like when you are constructing a taller building, you cannot just slap it twice on each other, because the foundations will collapse, and when you want to build a space elevator, you need technology that hasn't been invented yet.

June 8, 2017

Re: [Pharo-users] Traits, method flatten

by Hilaire

Yes, Nicolai proposed a fix, and it worked well enough. So it should make you happy. Hilaire Le 08/06/2017 Ã 06:00, Sean P. DeNigris a Ã©crit : > HilaireFernandes wrote >> I made another attempt to >> persist this time with filetree://. The net result is the same, the >> Traits logic is lost in the classes using the Traits: all traits methods >> are duplicated !! > I just got burned by this in ##50768. Methods inherited from traits were > saved as part of the package containing the extended class, as well as the > package containing the Trait itself. Ugh. Was this ever fixed by Pharo 6? > -- Dr. Geo http://drgeo.eu

June 8, 2017

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Peter Uhnak

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, 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. Well that is the objective of DI to handle the object creation on your behalf. Of course no class is prohibited from creating instances directly, provided it had the necessary dependencies to give to the instance. > Suddenly everything must be created through the DI container, but that is not true for Service Locator. As I've noted above, DI doesn't restrict you from creating instances. Service Locator gives you a more flexible approach, however it follows that it can be also harder to manage, as the services registered in the locator can (and typically do) change at runtime, which inhibits static reasoning about the dependencies, compared to a pre-fixed configuration. > > 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? In my previous mail I've mentioned Spec doing something of the sorts, but I don't think I've seen it anywhere else. The hand-wiring mostly suffices; sometimes you can see having a method containing the name of the class it will instantiate (and which can be altered in a subclass). My best guess would be that the capabilities of Pharo, such as pluggable closures, and being a live already-running system are more likely to push the programmer towards a different architecture, where incidentally DI's are not such a concern, but I would certainly love to see some deep analysis on this. Peter > > > cheers! > Vitor > > On Wed, Jun 7, 2017 at 9:32 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > > On Tue, Jun 6, 2017 at 11:48 PM, Attila Magyar <m.magyar3(a)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. > >> > >> > >

June 8, 2017

Re: [Pharo-users] is it related to Freetype or Athens?

by Hilaire

Another good reason to migrate Dr. Geo to Pharo 6 ;) Le 07/06/2017 Ã 21:53, Peter Uhnak a Ã©crit : > There were couple GC/memory related issues in the VM's plugin, that were fixed or worked around in the Pharo 6 VM that apparently were present for a long time... so maybe that's also part of what you've experienced... > -- Dr. Geo http://drgeo.eu

June 8, 2017

Re: [Pharo-users] ZnClient: how to emulate a curl command

by Offray Vladimir Luna CÃ¡rdenas

Hi Sven, I was making a silly mistake in the server URL. I just forgot the extra "/" after servers port number, so it was "8081/json" instead of "8081json". I imagine that maybe is a test for validating properly form urls, but also I will have a more trained eye for such errors next time. Now is working properly. The code at [1], shows the fix and includes the ZnEasy convenience. [1] http://ws.stfx.eu/PLUA8QCSI4X0 Cheers, Offray On 07/06/17 12:20, Sven Van Caekenberghe wrote: > Hi Offray, > >> On 7 Jun 2017, at 17:21, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Hi, >> >> I'm prototyping some integration between Fossil and Pharo for the >> creation of dynamic distributed web sites [1]. Now I would like to send >> some messages to store serialized STON domain objects as Fossil wiki >> pages. The command that makes this, using curl, is: >> >> curl -H "Content-Type: application/json" -d '{"authToken": "mytoken", >> "payload": {"name": "foo", "content": "bar"}}' >> http://localhost:8081/json/wiki/create >> >> and I thought that a similar command would be the one at [2], but there >> is something about ZnEntity that I'm not understanding. >> >> How can I replicate the curl command using ZnClient? >> >> [1] http://smalltalkhub.com/#!/~Offray/Brea >> [2] http://ws.stfx.eu/D61ZOA1LEQNG >> >> Thanks, >> >> Offray > That [2] looks about right to me. Though the URL is strange (the json part). What do you get as response ? Maybe the authentication just fails. Or you made some other mistake ? > > I would personally never write JSON manually, but like this: > > STONJSON toString: { #authToken->'foo'. #payLoad->({ #name->'test'. #content->'something' } asDictionary) } asDictionary. > > Or this: > > (NeoJSONObject new authToken: 'foo'; payLoad: (NeoJSONObject new name: 'test'; content: 'something')) asString. > > Different styles/frameworks, same result. > > Sven > > >

June 8, 2017

Re: [Pharo-users] Bloc/Brick/Spec

by Glenn CavarlÃ©

Hi Marc, It would be so cool but no, it's not planned. Like SDL and Morphic, Gtk is only used as a backend for windowing. This means that only primitives related to windowing are currently implemented (i.e GtkWindow related apis). Working on widget binding with Gtk or Qt is something i would like to start, maybe next year but it is quite hard/long to do well. The Mars framework built by Esteban was a really good starting point but it is not maintained. Thanks for your interest, Cheers, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-Brick-Spec-tp4949591p4950514.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 8, 2017

Re: [Pharo-users] Pharo6 server deployment and no home directory

by Holger Freyther

> On 17. Apr 2017, at 21:30, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi Holger, Hey Juraj! > Basically it tests `FileLocator home exists`, if false, it does not touch disk. We could also add a #disablePersistence method if necessary. I thought I tested it but somehow it is broken (again)? Looks like FileLocator>>#exists fails instead of answering false? Can you reproduce it? $ unset HOME $ pharo ... Error: Can't find the requested origin UnixResolver(PlatformResolver)>>cantFindOriginError [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: UnixResolver>>home [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self home / '.config' ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver>>preferences UnixResolver(FileSystemResolver)>>resolve: SystemResolver(FileSystemResolver)>>unknownOrigin: SystemResolver(FileSystemResolver)>>resolve: InteractiveResolver>>unknownOrigin: [ self unknownOrigin: origin ] in InteractiveResolver>>resolve: in Block: [ self unknownOrigin: origin ] IdentityDictionary(Dictionary)>>at:ifAbsent: InteractiveResolver>>resolve: FileLocator>>resolve FileLocator(AbstractFileReference)>>exists GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>shouldCallPreviousPersistence GlobalIdentifierStonPersistence(GlobalIdentifierPersistence)>>ensure: GlobalIdentifier>>ensure GlobalIdentifier class>>initializeUniqueInstance GlobalIdentifier class>>uniqueInstance SystemSettingsPersistence class>>resumeSystemSettings [ :persistence | persistence resumeSystemSettings ] in PharoCommandLineHandler>>runPreferences in Block: [ :persistence | persistence resumeSystemSettings ...etc... BlockClosure>>cull: SystemDictionary(Dictionary)>>at:ifPresent: SmalltalkImage>>at:ifPresent: PharoCommandLineHandler>>runPreferences PharoCommandLineHandler>>activate PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:

June 8, 2017

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Attila Magyar

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 inside the class that uses it, or a dependency (or peer) that should be passed as an argument. In the later case you instantiate the object from the outside and hand it over to the object that requires it. Most applications have a few major top level abstractions. Let's call them subsystems. I would use more domain specific names in a concrete case but this is a general example. These subsystems are instantiated at the entry point of the application. If there are shared dependencies between them, those are instantiated here as well. Then each subsystem can build up some object graph that is required by the actual subsystem (Not everything needs to know about everything else. There are clusters of objects that represent domain level abstractions). The same things applies here as well. Some dependencies are passed through (peers), others are instantiated (internals) from the inside. This can go on and on further and it will result a fractal like structure. The whole application is one object. It consists of few other objects. Those object consists of further objects. In a typical Spring application there is big blob of object soup with full of equivalent objects, everyone can access to everything else and this fractal structure is missing. -- View this message in context: http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4950… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 8, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Denis Kudriashov

2017-06-08 15:37 GMT+02:00 Steffen MÃ¤rcker <merkste(a)web.de>: > In fact, I moved from Mocketry to DoubleAgents quite some time ago... =) It was greatly updated from VW version. (look for details here http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html)

June 8, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Steffen MÃ¤rcker

In fact, I moved from Mocketry to DoubleAgents quite some time ago... =) Am .06.2017, 23:04 Uhr, schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-06-07 22:04 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> I read your note about DoubleAgents for the tests, well, yeah this one >> we >> do not have. I read about it on the blog of its maker and it looked >> decent >> indeed. >> > > I think Mocketry can easily replace DoubleAgents but API is different and > most tests will needed rewrites

June 8, 2017