>
>
> > As it sounds a lot like your definition of OOP to me.
>
> For sure, this code relies on messages passing. It is "functional" in the
> old sense that the messages are functions -- a usage of the word
> "functional" that any Lisper would have understood for decades. But it is
> not "funct
I'd like to see an example of this "functional worker" style you mention.
As it sounds a lot like your definition of OOP to me. Not to mention that
anything that talks to a queue is performing io and is therefore not
functionally pure. So it sounds like you went and re-built component, but
this tim
There are ways to handle dependencies without going down the OOP route that
Stuart Sierra took. However, there are a lot of good ideas in Stuart
Sierra's Component library, and to the extent that you can borrow those
ideas, you end up with code that resembles "best practice" in the Clojure
comm
All objects can as well be implemented with message passing, a functional
technique. However, if one would do it with stuartsierra/component, it
would be so trivial that you could hardly call the lib object "orientated".
On Friday, June 19, 2015 at 11:14:04 AM UTC+2, Serzh Nechyporchuk wrote:
>
OOP always talks about object (mutable or immutable) in terms of
polymorphism, encapsulation and inheritance. Components library misses only
inheritance, which, obviously, the "killer feature" in OOP. So we could say
that Components library that take good ideas from OOP.
If you want call something
oop means object oriented programming, which doesn't mean mutable. record
is oop and immutable. when you use java, you can asume everthing is
immutable.
if i use dynamic to implement the object, i can test it with "binding";
others i can test with "with-redefs". so it works, except side effect
OOP does not mean mutab... erh... anything, really, but there is an
argument to be made for calling an immutable blob that carries data and the
operations to act on it an "immutable object". If every "mutative"
operation returns a modified copy of the object, you can have immutable OOP.
On Thursda
How is stuartsierra/component OOP when it is building an immutable object
graph? (Contrast that to Guava etc.)
On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou wrote:
> hi guys,
>
> Constructing simple clojure project is trival, just make functions. if the
> project grows large, with more datasour
hi guys,
Constructing simple clojure project is trival, just make functions. if the
project grows large, with more datasources, message queue, and other
storages, dependencies problem is on the table.
One solution is stuartsierra/component, using system to configure
dependencies graph, make
