Re: Data vs API
Great question and great answers, thank you. Regarding (3), what if want to process various customer order implementations (say, sort them) in a polymorphic way depending just on their total-price? Assuming I do not control the implementations.. Is it ok in this case to define *HasTotalPrice* protocol (or *total-price*multimethod) and code against that? Or is it better to accept a data structure * along with *total-price-fn* function as an additional parameter? * with :*total-price-fn* as a part of the data structure? * with *:total-price* value already computed? Thanks for any hints.. On Thursday, May 3, 2012 8:30:33 AM UTC+12, stuart@gmail.com wrote: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? (1) You always have to choose a representation for your data. (2) Having chosen a data representation, if you make an accessor function API, you now have two representations. This is the very opposite of DRY. If you think that the representation implied by the accessor functions is better/more stable than the data representation, then choose a data representation like the one implied by your accessor functions. (3) If you have helper functions for dealing with a particular representation, those helpers can and should be separate from the representation itself. For example, a customer order is some combination of maps, vectors, etc. totalPrice is never a member function of some accessor-riddled Order object -- it is instead a plain function that knows how to navigate a data representation (or, via a la carte polymorphism, many different representations). Cheers, Stu Stuart Halloway Clojure/core http://clojure.com -- -- 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.
Re: Data vs API
Antonio, I think he means that the onus is on the consumer of an API to make a sensible decision about what they depend on. Consumers could choose to depend on implementation details rather than provided abstractions. When they do so, they need to accept the burden of adapting should those implementation details change. Language constructs e.g. data hiding, can sometimes forcibly prevent consumers from depending on implementation details. But Rich's philosophy is that we should trust programmers to judge the trade-offs of depending on particular implementation details. The argument is that anyone who can't adequately weigh up those tradeoffs and chooses to depend on inappropriate parts of an API lacks the judgement of a good programmer. The Clojure community would generally rather to optimise for the case of the skilled and rational programmer than introduce complexity designed to save people with poor judgement from themselves. If someone wants to build code around details of your data structures, let them. Cheers, Chris On Sunday, May 6, 2012 8:11:13 PM UTC+3, Antonio Shastun wrote: can any one explain to me please If people don't have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers. четверг, 3 мая 2012 г., 3:35:04 UTC+3 пользователь Takahiro Hozumi написал: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? I think Rich's comments in an interview with Fogus is helpful. http://www.codequarterly.com/2011/rich-hickey/ Fogus: Following that idea--some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding? Hickey: Let's be clear that Clojure strongly emphasizes programming to abstractions. At some point though, someone is going to need to have access to the data. And if you have a notion of private, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn't. This is in addition to the other losing that occurs when simple information is put into classes. To the extent the data is immutable, there is little harm that can come of providing access, other than that someone could come to depend upon something that might change. Well, okay, people do that all the time in real life, and when things change, they adapt. And if they are rational, they know when they make a decision based upon something that can change that they might in the future need to adapt. So, it's a risk management decision, one I think programmers should be free to make. If people don't have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers. 2012/5/2 Mark markad...@gmail.com javascript:: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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 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
Re: Data vs API
can any one explain to me please If people don't have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers. четверг, 3 мая 2012 г., 3:35:04 UTC+3 пользователь Takahiro Hozumi написал: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? I think Rich's comments in an interview with Fogus is helpful. http://www.codequarterly.com/2011/rich-hickey/ Fogus: Following that idea--some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding? Hickey: Let's be clear that Clojure strongly emphasizes programming to abstractions. At some point though, someone is going to need to have access to the data. And if you have a notion of private, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn't. This is in addition to the other losing that occurs when simple information is put into classes. To the extent the data is immutable, there is little harm that can come of providing access, other than that someone could come to depend upon something that might change. Well, okay, people do that all the time in real life, and when things change, they adapt. And if they are rational, they know when they make a decision based upon something that can change that they might in the future need to adapt. So, it's a risk management decision, one I think programmers should be free to make. If people don't have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers. 2012/5/2 Mark markaddle...@gmail.com: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? -- 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 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
Re: Data vs API
Thanks all, folks. Rich's video helped tremendously. The a-ha moment was the realization that the biggest reason to abstract data access in Java is the non-uniform built-in access to data: accessing fields in objects is different from hashmaps which is different from instance access which is different from static data. Clojure's uniformity neatly solves that problem. As I'm getting more familiar with destructuring and Clojure's polymorphism, I realize that I was anticipating more of a problem with fluid data structures than they turn out to be. -- 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
Data vs API
I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? -- 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
Re: Data vs API
I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? Good question. Now drop everything and go watch this talk by Rich - http://www.confreaks.com/videos/860-railsconf2012-keynote-simplicity-matters I hope the talk will answer some of your questions, if you have some more, feel free to ask this list :-) Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- 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
Re: Data vs API
On Wed, May 2, 2012 at 7:03 AM, Mark markaddle...@gmail.com wrote: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. not clojure, but a lisp, and representative of the Great Divide. http://lists.racket-lang.org/users/archive/2010-April/038935.html :-) -- 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
Re: Data vs API
The data *is* the API. Design the data structures you're going to accept return at all the public entry-points of your library or application. That's your API design. It's kind of like web APIs returning JSON or XML: the structure of the data you get back is part of the contract. -S -- 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
Re: Data vs API
On Wed, May 2, 2012 at 12:27 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: The data *is* the API. Design the data structures you're going to accept return at all the public entry-points of your library or application. That's your API design. It's kind of like web APIs returning JSON or XML: the structure of the data you get back is part of the contract. hmm. entities can be represented in different ways, even with different views of them, e.g. in REST, no? and with HATEOAS exposing the actions in a context-sensitive way. and you need to define what the REST HTTP action verbs mean for them. otherwise you just have something more CRUDy than RESTy? (not that one can never desire CRUD.) so design it seems would have to take into consideration both data and behaviour, they are inter-twined, at least. of course one might wish to pick one or the other as the starting off point for thinking about the design. -- 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
Re: Data vs API
Can you give an example of how your data structure changes? Getters and setters are only a problem when they come baked into your datastructure, as the only way to access the contents. If you require more custom getting/setting logic than the built-in datastructures provide, you can always just write a function that does something more complex, and pass the datastructure in as an argument. Its useful to realize that in datastructures, complexity bubbles up, and thus having simpler components makes your problem go away. If your datastructure contains a bunch of components that themselves have their own setters and getters, your datastructure needs to define yet another pair of setters and getters because you need to abstract away the variations in your components. If the components all all just clojure maps, sets, and vectors, then you don't have this problem of needing to account for all this variation. On Wed, May 2, 2012 at 10:03 AM, Mark markaddle...@gmail.com wrote: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? -- 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 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
Re: Data vs API
A nice example of this in clojure is ring: https://github.com/mmcgrana/ring The essence of it is what keys are present in the request/response maps, laid out here https://github.com/mmcgrana/ring/blob/master/SPEC On Wed, May 2, 2012 at 3:27 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: The data *is* the API. Design the data structures you're going to accept return at all the public entry-points of your library or application. That's your API design. It's kind of like web APIs returning JSON or XML: the structure of the data you get back is part of the contract. -S -- 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 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
Re: Data vs API
I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? (1) You always have to choose a representation for your data. (2) Having chosen a data representation, if you make an accessor function API, you now have two representations. This is the very opposite of DRY. If you think that the representation implied by the accessor functions is better/more stable than the data representation, then choose a data representation like the one implied by your accessor functions. (3) If you have helper functions for dealing with a particular representation, those helpers can and should be separate from the representation itself. For example, a customer order is some combination of maps, vectors, etc. totalPrice is never a member function of some accessor-riddled Order object -- it is instead a plain function that knows how to navigate a data representation (or, via a la carte polymorphism, many different representations). Cheers, Stu Stuart Halloway Clojure/core http://clojure.com -- 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
Re: Data vs API
I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? I think Rich's comments in an interview with Fogus is helpful. http://www.codequarterly.com/2011/rich-hickey/ Fogus: Following that idea—some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding? Hickey: Let’s be clear that Clojure strongly emphasizes programming to abstractions. At some point though, someone is going to need to have access to the data. And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t. This is in addition to the other losing that occurs when simple information is put into classes. To the extent the data is immutable, there is little harm that can come of providing access, other than that someone could come to depend upon something that might change. Well, okay, people do that all the time in real life, and when things change, they adapt. And if they are rational, they know when they make a decision based upon something that can change that they might in the future need to adapt. So, it’s a risk management decision, one I think programmers should be free to make. If people don’t have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers. 2012/5/2 Mark markaddle...@gmail.com: I've read in some recent posts that Clorujians prefer data to APIs. I'm not sure I understand what this means, in practice. When I'm in the early stages of developing an application, the data structures undergo a great deal of change. One of the ways, I isolate parts of the code from these sorts of changes is by writing accessor functions. Maybe this is OO thinking but it seems to me a wise application of DRY. Would these accessor functions be considered an API? If so, why should I prefer accessing the raw data structure? If not, what is constitutes an API? -- 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 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
