On Sun, May 20, 2012 at 2:23 PM, Warren Lynn <wrn.l...@gmail.com> wrote: > Well, I don't want to be a beginner for too long, :-)
then "As a Clojure programmer you should only need them rarely." > On May 20, 5:19 pm, Kevin Downey <redc...@gmail.com> wrote: >> 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 -- 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
