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
