--
Kurt Harriger
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Saturday, June 16, 2012 at 3:07 PM, Kurt Harriger wrote:
>
>
> 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
> > (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.
>
I disagree... and 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]
> > > (mailto:[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]
> (mailto:[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]
> (mailto:[email protected])
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
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
