>
> 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.
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.
> 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.
> 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.
Actually this is only somewhat contrived. It is not uncommon for a user to
> the same nickname in his email nickn...@domain.com 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.
--
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
