wondering the reasons to choose defrecord vs reify in stuartsierra/component

[Juan A. Ruz @tangrammer]

Hi guys, 

I'm just wondering the pros/contras that justify to choose defrecord vs reify as component fn constructor.

in the component README we can read 

"To create a component, define a Clojure record that implements the Lifecycle protocol."

Yes I know that "defrecord creates an immutable persistent map which implements a protocol." but I think that the same thing can be achieved with reify (BTW: "om" way to define component) over a persistent map... 

Do you think there are more reasons to set defrecord as default base fn for components?

Thanks in advance

Juan

[James Reeves]

Often because components contain some form of data. For instance, a component that handles database connection may have a database connection instance.

Reify produces objects that are essentially opaque, which is fine if you just want their behaviour, as in the case of Om, but not so good if you also want to carry around some form of data.

Records are even useful for components that aren't usually dependencies, like a web server. Even though you may only need to start and stop the server component, it's often useful for debugging or monitoring purposes to be able to query the options that the server was set up with.

- James

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JUAN ANTONIO RUZ]

Hi James

I got this question after watching the David Nolen's  video called "The Functional Final Frontier". Around minute 11th he talked about "Local state is poison" idea and how he tried (using cursors) to remove this local state from Om design 

After those David Nolen design ideas, it seems to me that stuartsierra/component is inclined on local state ("Managed lifecycle of stateful objects in Clojure") more than global tree structure state... 

Thanks for your clarification!

Juan

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xqU_JSFWK-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Stuart Sierra]

Hi Juan,

Components are records in order to support the dependency-injection features of `component/start-system`, which work via `assoc`.

There are potentially many other ways to do dependency injection, but I found `assoc` to be practical.

If you want to create a component that has a Lifecycle but no dependencies, then `reify` will work just fine.

If you want to create a component that has dependencies but no Lifecycle, then an ordinary Clojure map will work.

–S

[JUAN ANTONIO RUZ]

Hi Stuart, 

Components are records in order to support the dependency-injection features of `component/start-system`, which work via `assoc`.

That was the only reason that I could imagine but I wanted to double checked here :) I'm always inclined to think in performance reasons that I don't know yet 

I was thinking in having a protocol to replace this practical `assoc` behaviour of defrecor. So we can get components working with a global state tree structure instead of local state

Thanks for having the time to answer this question!

Juan