On Sun, May 20, 2012 at 2:13 PM, Warren Lynn <wrn.l...@gmail.com> wrote: > Maybe for Person/Employee example with very simple functions do not > need data types, but I don't think that is generally true (isn't > "defrecord" trying to patching that up?). When I say "need" I am not > saying you cannot achieve what you want to do without it (just as > assembly code can do anything), but things will get so flexible (hence > the lack of pattern) the language will be "powerful" only on paper > very soon. I am glad Clojure does not seem to be heading that > direction, but still I think there might be things we can improve on.
defrecord, deftype, and defprotocol provide extensible low level abstractions like the kind Clojure is built on. As a Clojure programmer you should only need them rarely. As a beginner you should never use them. > On May 20, 4:51 pm, Kevin Downey <redc...@gmail.com> wrote: >> On Sun, May 20, 2012 at 10:22 AM, Warren Lynn <wrn.l...@gmail.com> wrote: >> > So from what I read the philosophy of Clojure discourages inheritance >> > on concrete data types. However, maybe I am too entrenched in my OO >> > thinking, how do I define a new record type that includes all the data >> > members of another record type? I am thinking about the classic >> > Employee/Person example. >> >> Don't make data members. Use maps and multimethods. You don't need >> types for this. You have data about a thing, keep it has data, >> suddenly all the functions that work on data structures (select-keys, >> update-in, clojure.set) all work on your data instead of having your >> data locked away in a type. >> >> >> >> >> >> >> >> >> >> > If I can define a record of Employee with Person's data members >> > included, even that is not true inheritance (as no protocols of >> > "Person" will be automatically extended to "Employee"), I need that >> > for function re-use (so a function working on Person will >> > automatically work on Employee because Employee is guaranteed to have >> > all the data members in Person). >> >> > Also, again, maybe I am too OO minded, is there a way inherit another >> > record type's protocol implementation? That seems to give the best >> > combination of both worlds (OO and functional), so you can either have >> > you own very customized combination of data type/protocols, or use the >> > very common OO pattern. Just like we have both the single-typed >> > dispatching (which is more OO like and covers a large portion of use >> > cases), and more advanced multimethods. >> >> > Thanks. >> >> > -- >> > 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 >> >> -- >> And what is good, Phaedrus, >> And what is not good— >> Need we ask anyone to tell us these things? > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
