Will just add, in re: an earlier thread on this talk, one way to view this is in re: the lifespan of the data.
Building and evolving the components that deal with live data passed around between them is easier and more fluid when working with maps than with working with types. One can add a field to a map without changing anything else, often not so when adding a field to a class. Exposing data directly in the data structure, rather than hiding it behind methods, forces better data flow and management decisions and simplifies changes. The classic example is of first and last name fields in a class that get combined in a getFullName() method. Then something in the business rules changes and you need to take a full name and decompose it into a first and last. Performing changes like this is less work in a data flow design, more work in OO with data encapsulation. There are all sorts of decisions that one has to make with types when working solely within an application that arguably create incidental complexity. Types can bring more value at the edges- when exchanging data between applications, and when persisting data in a durable form. And as with the other responses- don't think of protocols as tied to the data. They are not wrappers around data. Instead, think of them as their name implies- protocols can be used to crisply describe how 2 components, the caller and the callee, *participate* in an interaction (a "protocol") around different concrete bundles of data. (Though as in the other responses, it's probably often the case that the interactions are not really that crisp, so multimethods are a better choice for polymorphism.) On Sun, Jan 19, 2014 at 2:55 PM, Brian Craft <craft.br...@gmail.com> wrote: > http://www.youtube.com/watch?v=ROor6_NGIWU > > Around 56:28 Rich is talking about whether components pass a data > structure, or "an object that has all these verbs and knows how to do stuff > ...". > > Clojure data types also have verbs, in protocols, and if one component > passes a record to another component, the receiver will need to use those > verbs to make use of the data. How is that different than the OOP example? > There's the syntactic difference that in OOP you write it object, verb, > arguments, and in clojure you write it verb, object, arguments. But that's > trivial. How is it architecturally different to pass an object with methods > vs passing a record with protocol? > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
