Re: separation of concerns w/o encapsulation

> Once an engineer comes to grok FP, they tend to organize code around how > data 'flows' between these pure functions to produce output data. The > structure of how functions connect to form the structure of a functional > computation has typically been informal. Until now see Flow Based Prog

Re: separation of concerns w/o encapsulation

pasting here what I think could be a separation of concerns code pattern proposal from "Graph: Abstractions for Structured Computation" *... Object-oriented programming encourages the decomposition of large systems into

Re: separation of concerns w/o encapsulation

On May 14, 2015, at 12:37 PM, Erik Price wrote: > The code itself is mutable. The nice thing about a private function is that I > have reserved the right to change how it works someday, without fear that > others have become dependent on the way it currently works. That’s why I suggested foo.ap

Re: separation of concerns w/o encapsulation

That assumes the intermediate functions are reusable. I guess with all these things asthetics come into play, and there is of course the option of letfn as well. On 14 May 2015 18:40, "Sean Corfield" wrote: > On May 14, 2015, at 10:28 AM, Colin Yates wrote: > > I guess a related concern is abstr

Re: separation of concerns w/o encapsulation

On Thu, May 14, 2015 at 12:14 PM, Sean Corfield wrote: > > In an environment where you can’t trust your co-workers(!), you certainly > want to hide *mutable* data so they can’t modify your objects’ state. When > you remove mutability, there’s a lot less damage they can do and they it’s > really m

Re: separation of concerns w/o encapsulation

On May 14, 2015, at 10:28 AM, Colin Yates wrote: > I guess a related concern is abstraction. I notice I often have functions > which work at different levels of abstraction in the same ns which makes me > uncomfortable. In OO land they would be package level or even instance > classes. I haven'

Re: separation of concerns w/o encapsulation

I guess a related concern is abstraction. I notice I often have functions which work at different levels of abstraction in the same ns which makes me uncomfortable. In OO land they would be package level or even instance classes. I haven't yet found a way to solve this in clojure land. To be expli

Re: separation of concerns w/o encapsulation

On May 13, 2015, at 11:07 PM, Brian Craft wrote: > http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism > > In an environment where you

Re: separation of concerns w/o encapsulation

http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism On Wednesday, May 13, 2015 at 1:09:48 AM UTC-7, Juan A. Ruz @tangrammer wrote: > > Hi guys, > when you talk about encapsulation do you mean using defrecords + protocols > ? > In this case, w

Re: separation of concerns w/o encapsulation

Hi guys, when you talk about encapsulation do you mean using defrecords + protocols ? In this case, we are talking of choosing defrecords instead of plain functions. Maybe it would be better if we talk too about the drawbacks of this choice. For example, can we compose or extend protocol functio

Re: separation of concerns w/o encapsulation

On Tuesday, May 12, 2015 at 4:29:22 AM UTC-7, Georgi Danov wrote: > > coding and designing defensively because you are concerned about your > teammates is big waste of time. if this is the reality (in the enterprise > it's the norm) > Yes, it is the norm in the enterprise. In a decade of ente

Re: separation of concerns w/o encapsulation

No tool or technology beats the combination of: a) component/responsibility blueprint b) discipline in communicating, following and adapting it encapsulation can be a nice safety net once you have the things above, but it would never be a solution to the problem. just a convenience. coding and d

Re: separation of concerns w/o encapsulation

Thanks, everyone, this has been very helpful. On Sunday, May 10, 2015 at 8:28:37 AM UTC-7, Stuart Sierra wrote: > > I find it's really the same as in any other language. Certainly if you > don't have any clearly-defined boundaries at all, you'll get a big ball of > mud. > > Encapsulation is abou

Re: separation of concerns w/o encapsulation

If your modules are becoming big and unwieldy, you can also take a step toward (conceptual) OO and have your modules be separate entities that communicate through message passing (i.e. objects, although probably closer to Erlang's processes than Java objects). Messages are the key missing piece of

Re: separation of concerns w/o encapsulation

Brian One is better off thinking that avoidance, as per your note, is a *discipline* of *better practices. *As the architectural concepts of Separation of Concerns and Minimized Surface Areas were intended. Many languages attempt to enforce this notion in something called encapsulation. Howeve

Re: separation of concerns w/o encapsulation

I find it's really the same as in any other language. Certainly if you don't have any clearly-defined boundaries at all, you'll get a big ball of mud. Encapsulation is about code organization and self-discipline. Define module responsibilities and boundaries in your developer documentation. Mak

Re: separation of concerns w/o encapsulation

On 8 May 2015 at 18:40, Andy Fingerhut wrote: > James, are you saying that with such a core.typed annotation for function > available in that example, that it would give a warning if available or any > of the functions it calls accesses any keys other than :stock and :reserved > ? > Yes and no.

Re: separation of concerns w/o encapsulation

James, are you saying that with such a core.typed annotation for function available in that example, that it would give a warning if available or any of the functions it calls accesses any keys other than :stock and :reserved ? If so, that is quite impressive. Andy On Fri, May 8, 2015 at 10:36 A

Re: separation of concerns w/o encapsulation

Avoiding encapsulation doesn't mean that every function needs to act on a huge global data structure. On the contrary, one of the core ideas of Clojure is that we should try to reduce incidental interconnections. What you describe in your example is essentially complexity creep. Ideally, functions