Channels
#announcements
- k
kmruiz
05/08/2016, 7:41 PMas far I see, probably I'm wrong, extension functions are useful when adding logic to existing classes when this logic doesn't depend on external state - k
kmruiz
05/08/2016, 7:41 PMfor example, if it doesn't use an external system, like the DNS - k
kmruiz
05/08/2016, 7:41 PMif I use the client, I don't want to know nothing about which DNS resolution strategy I want to use - k
kmruiz
05/08/2016, 7:42 PMIMHO in this case in particular, I would create a facade over DNS connection - k
kmruiz
05/08/2016, 7:43 PMNetwork.connectTo(domainName: DomainName): DNSClient - k
kmruiz
05/08/2016, 7:43 PMNetwork.connectTo(ip: String): IPClient - k
kmruiz
05/08/2016, 7:43 PMnetwork not being a singleton - k
kmruiz
05/08/2016, 7:43 PM😛 - o
orangy
05/08/2016, 7:43 PMI don’t understand. If you are fully into DI/IoC world, then you got
instance via injection. So we are either talking aboutClient
,Client(IPConnector, DNSResolver)
or we are talking aboutUserClass(Client)Client(IPConnector), UserClass(Client, DNSResolver) - k
kmruiz
05/08/2016, 7:44 PMIf I use an extension function, I can't resolve the dependency on build time - k
kmruiz
05/08/2016, 7:44 PMI'm more about the first than the second - k
kmruiz
05/08/2016, 7:44 PMPS: this could be resolved by kotlin with partial application - o
orangy
05/08/2016, 7:44 PMSo, you can’t use different dns resolvers in different parts of your system? For DNS it hardly makes sense, but for many other does. - k
kmruiz
05/08/2016, 7:45 PMthis depends on the scope of course - k
kmruiz
05/08/2016, 7:45 PMbut I usually don't need to do that decision - k
kmruiz
05/08/2016, 7:45 PMAnd usually DI frameworks can make that kind of decisions - k
kmruiz
05/08/2016, 7:46 PMmyService1 use a public DNS, myService2 only uses /etc/hosts - z
zoltu
05/08/2016, 7:46 PMDNS it makes sense because you don't want your tests actually going to the OS to resolve DNS. - o
orangy
05/08/2016, 7:46 PMthen you’ll have to have two Clients - z
zoltu
05/08/2016, 7:46 PMI would DI a DNS resolver. - k
kmruiz
05/08/2016, 7:46 PMyep, two clients for two different things - k
kmruiz
05/08/2016, 7:46 PMfor me has sense - z
zoltu
05/08/2016, 7:46 PMBut I can see the value in having an extnsion method that takes the DNS resolver rather than the client constructor. - k
kmruiz
05/08/2016, 7:47 PMme too - k
kmruiz
05/08/2016, 7:48 PMif I'm working in a low level library that makes that kind of decisions in runtime, having the DNS resolver as a parameter makes sense - o
orangy
05/08/2016, 7:48 PMOkay, we are deluded into di/ioc talk simple smile - k
kmruiz
05/08/2016, 7:48 PMthat's why I hate Guice😛 2 - k
kmruiz
05/08/2016, 7:49 PMback to the topic 😛 - k
kmruiz
05/08/2016, 7:49 PMwas extension functions simple smile, having extension functions for the Open Close principle is very useful - k
kmruiz
05/08/2016, 7:49 PMbut I don't see the point to modularize myself my apps or libraries with extension functions