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.
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
