50 years of solid programming principles, OO being the Holy Grail ? :)
I assume then that you programmed a lot in Simula-66 ? I did...
For over 50 years, we made the same mistakes that Clojure attempts to
correct. Most of the time new languages repackaged the same flawed concepts
of the past, this has been done over and over again.
Programmer's throughput have to increase somehow, any superfluous line of
code is too many.
Getters facades of any form are just that, superflous code lines that need to
be maintained later on.
That led Java right in the russian puppet syndrom.
In these 50 years solid principles, many failed to deliver. It's time for a
reset :)
Luc
>
>
> 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 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.
> >
>
> 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 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
--
Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
--
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
