Hi James,
I'm not basing logic on types alone. That aside, here's an example to
highlight the specific problem:
{:where [:id 'identity]}
Here are two options for sorting by id:
1. {:where [:id 'identity] :sort-by :id :sort '>}
2. {:where [:id (object 'identity {:sort >})}
I chose #2, which is immensely helpful when constructing multi-sort
queries. I can understand how #2 may raise some eyebrows/questions from a
query logic perspective, but I am trying to reduce the scope down to
question at hand and not get into unraveling the entire spec.
Does that help? & Thanks.
On Thursday, December 12, 2013 7:59:26 AM UTC-5, James Reeves wrote:
>
> It's hard to offer an opinion without some sense of the data structures
> you are producing.
>
> In the case of sorting by identifier, why do you need a new type? It
> sounds like you're basing your logic on data types, rather than the data
> itself.
>
> - James
>
>
> On 12 December 2013 04:26, Tim <tcr...@gmail.com <javascript:>> wrote:
>
>> As an experiment, I've written a DSL that generates database queries
>> using *effectively* only the data. The query logic is derived from the data
>> assemblance and choice of data structures (or types). I am at the stage
>> where I have all the logic working, and I am now moving into perf testing
>> and tuning. BUT, before I do, there's this one hack I have implemented that
>> has me asking the this question.
>>
>> As I wrote the DSL I ran out of data structure types to account for a few
>> defined meanings within the query logic. As a short term hack I decided to
>> attach meta data to symbols where the meta data contained a data value
>> along with, for example, a sort option. I only intended for this to be
>> short term until I got around to figuring out the semantics of Clojure's
>> deftype or defrecord.
>>
>> Here's the hack:
>>
>> (defn object [v m]
>> (let [id (gensym #"object#")]
>> (with-meta id
>> (merge m {:default v :id id}))))
>>
>>
>> (defn object? [o]
>> (if-let [it (meta o)]
>> (if (= (it :id) o)
>> true false)
>> false))
>>
>> (defn inspect
>> ([o]
>> (inspect o nil))
>> ([o & xs]
>> (if-let [it (meta o)]
>> (if (= (:id it) o)
>> (if-let [x (first xs)]
>> (if (coll? x)
>> (select-keys it x)
>> (x it))
>> it)))))
>>
>> (defn instance
>> ([o]
>> (instance o nil))
>> ([o & args]
>> (if-let [it (meta o)]
>> (if (= (:id it) o)
>> (if-let [x (:default it)]
>> (if (fn? x)
>> (if-let [args (or (and (some identity args) args) (it
>> :args))]
>> (apply x args)
>> (x))
>> x)
>> it)))))
>>
>>
>> => (def o (object #(java.util.UUID/randomUUID){:sort '>})
>> object#24397
>>
>> => (object? o))
>> true
>>
>> => (instance o)
>> #uuid "3c9cca8b-59e2-46b2-9175-468de3a21a22"
>>
>> => (inspect o :sort))
>> >
>>
>> So now I've been reading up on Clojure's deftypes & defrecords and while
>> it I expect they are both considered the right tool for the job,
>> everything I read seems like overly complicated bloat code compared to my
>> hack. Am I missing something? Is this a case where you wouldn't be caught
>> dead using the above hack? Why or why not?
>>
>> As I see it: I'm not creating and/or holding millions of objects that
>> would need to be shared, altered or held onto. These have relatively short
>> lives that only serve in compiling to a different query language. Type
>> hints or java interop really shouldn't matter.
>>
>> Notes:
>>
>> 1. While the above function names may carry OO concepts, these functions
>> are not intended to fulfil all of them them; rather they only fill a
>> specific functionality gap that appears to meet my needs.
>> 2. I realize one wouldn't sort on a UUID, it's just an example to show
>> the functionality. :)
>>
>>
>> Thanks,
>> Tim
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
