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