On Saturday, June 16, 2012 1:28:21 PM UTC-6, Vinzent wrote:
>
> I agree, an explicit type field makes dispatching easy. However this data
>> structure returned by (http/get ... :as json) so if I want to add type
>> information I need to walk the tree and rewrite it. Not necessarily a bad
>> idea, but in some cases the only thing I need is the eTag and so the
>> additional processing may in some cases unnecessary. One could easily make
>> data conversions lazy by doing something like (defrecord Contact [contact])
>> (defmethod emails Contact [contact] (map map->Email (:emails contact)) to
>> delay the computation until the values are actually requested. However,
>> note that emails is now a multimethod method not a value and the consumer
>> needs to use (emails contact) rather than (:emails contact)... Thus as I
>> was saying previously is that (def emails :emails) gives you the
>> flexibility to delay computation if desired.
>>
>
> You have delays and lazy sequences for delaying computation.
>
This still requires changing your code to @(:emails contact). If you use
(emails contact) you need change your code in only one place.
>
> Clojure does not distinguish between properties and data representation
>> and these are NOT the same thing.
>>
>
> Properties is OOP concept; clojure is not an object-orinted language.
>
>
>> There are many different ways to represent data. For example the area of
>> a shape can be represented in many different ways, square inches, square
>> miles, a rectangle, circles, polygons, or perhaps complex geometry
>> requiring calculus all of which could be asked what is your area in square
>> feet. Area is a property of the object, the width, radius, number of
>> sides, etc is an implementation detail.
>>
>
> No, area is a function.
>
Property is just the OO word for function, semantically they are the same.
OO doesn't have functions they have properties and methods.
>
>
>> You may then ask so why don't you just pass in {:area } as square feet
>> instead of the radius of the circle? Because the value may not be used by
>> the function. If its not used then why is it part of the contract?
>> Because it may be used conditionally, for example, maybe the function
>> needs to find the first shape that will fit within a region once that limit
>> is reached it no longer requires the area for any other shapes. So if the
>> shape requires complex calculus which has been written in another
>> programming language and thus requires a rpc call to a network service to
>> compute the value that is only used sometimes seems wasteful and
>> inefficient if the value is only sometimes computed. This example is
>> somewhat contrived, but it is not that different from what I am doing.
>>
>
> If getting a 'property' requires such computations, then it's clearly
> should be a function.
>
Agree.
>
>
>> My point is that properties with getter functions allow you to defer
>> computation, keywords do not. Keywords are not like java getters they are
>> like java fields.
>>
>
> Keywords are just one of clojure's data structures (see
> http://clojure.org/data_structures#Data
> Structures-Keywords)
>
>
>> Instead of (:property themap), one should use (def property :property)
>> (property themap).
>>
>
> No, one shouldn't.
>
I disagree... but I will continue to recommend otherwise.
>
> Actually this is only somewhat contrived. It is not uncommon for a user
>> to the same nickname in his email [email protected] and in twitter
>> handle, and this is a useful similarity feature when this computation is
>> performed for each *pair* of field in each *pair* of contacts this
>> computation may need to be performed millions of times.
>>
>
> Well, you can use memoization or choose to structure your data in some
> other way.
>
>
>> Perhaps lisp programmers already did? CLOS and OO was born?
>>
>
> Clojure is not Common Lisp.
>
Agreed, clojure has a much stronger emphasis on immutability than
traditional OO programming and is what I like about it... but it is
possible to write OO code using immutable data structures but is not as
idiomatic. I don't want clojure to be like CLOS, but I also don't think
that we should ignore more than 50 years of lessons learned and "SOLID"
programming principles.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
