>
> I do use pre-conditions where the test condition is simple, ie is this a
> string? does the map have a :field-type? however I get a lot of my input
> data from http requests as json which have similar structures but different
> semantics, so I often do not have preconditions where type is not
> explicit. For example a string could be an list id or a contact id or an
> encoded json document. While it is possible to try to parse a string for
> json to verify its type this is seems very computationally expensive and
> therefore usually inferred from the context.
>
Why do you care about computational expensiveness of pre and post
conditions? They'll be turned off in production anyway.
> For example, my first contact model I had {... :fields [{:field-type
> :email :value "" ...}]} I later realized that the endpoint to get the
> contact information provided them grouped and I was filtering a lot based
> on field-type anyway so a more effective data structure was {:emails
> [{:value "" ...}]}, :field-type was just an implementation detail, the
> email object still has a value and associated behavior but the map no
> longer contains a :field-type. However, phone numbers have exactly the
> same {:value ""} structure so the only way to determine if it is an email
> or a phone number is from context or by parsing the string.
>
I believe using records or adding :type metadata would be an ideal fit in
this case.
I also tried using multimethods instead of protocols, but I still found I
> needed to restart the JVM frequently. I think whenever I would re-eval the
> namespace with the record type and (defmethod ...) a new class file would
> be emitted and the objects in my swank session need to be recreated.
>
defmulti has defonce semantic; you can use (def foo nil) (defmulti foo ...)
to workaround this. A topic about this problem was recently created in dev
mail list, so it'll probably be fixed soon.
I disagree. Ironically, if you told a java developer that getters were a
> premature optimization and he should use fields instead he would look at
> you funny. Getters are not an optimization and if anything have a minor
> performance penalty. However, using fields makes one very dependent on
> implementation details doing so is considered bad practice. I don't see how
> this is any different in clojure.
>
In clojure, structure of your map is a part of the contract. It's not an
implementation detail - it's the same as getters\setters in java.
> For example, my email data structure currently has just {:value "
> u...@domain.com"} however for various reasons it might actually be
> beneficial for me to use {:user "user" :domain "domain.com"}.
>
Well, this is a contrived example, since you'd use a plain string instead
of a map with the single :value key :) Given that, user and domain would
probably be functions.
There are still a lot of things I like about clojure, immutable persistent
> data structures, equality semantics, meta programming and embedded
> languages such core logic, cascalog, etc. Abstraction and data hiding are
> different things. In OO I too think private methods are a code smell,
> (they should be moved to public methods within another class), but the
> clojure community seems to believe encapsulation is only about data hiding
> and does not currently seem to value the age old abstraction principle.
>
I think it's rather in the process of finding it's own way of creating
abstractions.
--
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
