On Sun, May 20, 2012 at 2:05 PM, Warren Lynn <wrn.l...@gmail.com> wrote: > I don't quite understand where I introduced the rigidity. And what I > described is not a true inheritance as in traditional OO languages > (hence the quoted "inheritance"). It seems just some simple almost > syntax-level change (maybe some macros can solve it) will make > people's life a little bit easier
"2. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process." -- http://www.cs.yale.edu/quotes.html putting your data in specific types like Employee and Person instead of just using maps is a kind of rigidity > On May 20, 4:55 pm, Kevin Downey <redc...@gmail.com> wrote: >> On Sun, May 20, 2012 at 1:50 PM, Warren Lynn <wrn.l...@gmail.com> wrote: >> > Thanks. That will work. But I wish things can get more concise and >> > elegant. >> >> > I like the Python idea of "make simple things easier and difficult >> > things possible". So I think the limited "inheritance" I mentioned can >> > make a large portion of use cases easier, without sacrificing any of >> > Clojure's more advanced features. Basically, I wish to have something >> > like: >> >> > 1. (defrecord Employee [x y] :base Person) >> > so I can have all data fields in Person also included in Employee >> > 2. (extend-type Employee >> > GetName :reuse Person) >> > so I simply reuse GetName implementation from Person >> >> you have no reason to give up the flexibility of maps and data for the >> rigidness of types and an object graph. >> >> {:employee? true} beats the above hands down. >> >> >> >> >> >> >> >> >> >> > Maybe there is already something like that I am not aware of. But if >> > not, I really hope more people will concur and so it will get into the >> > language. >> >> > More broadly, I think the success of a language depends on two things: >> > 1. Flexible so it is not just usable on trivial problems. >> > 2. Provides/encourages good patterns so the flexibility won't get out >> > of control, especially on large projects. >> >> > Of course the challenge is how to balance these two. OO provides very >> > natural patterns for people to work with, so I think we should embrace >> > it as much as possible without sacrificing the unique flexibility/ >> > power Clojure brings. >> >> > On May 20, 1:56 pm, Vinzent <ru.vinz...@gmail.com> wrote: >> >> You can reuse methods by putting them in a map and then just merging it >> >> with the new methods: >> >> >> (extend Employee >> >> AProtocol >> >> (merge default-implementation {:new-function (fn ...)})) >> >> >> The problem is that you can't reuse methods defined inline, i.e. you can't >> >> say "my record implements this protocol just like that other record". >> >> >> воскресенье, 20 мая 2012 г., 23:22:55 UTC+6 пользователь Warren Lynn >> >> написал: >> >> >> > 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. >> >> >> > 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
