gen-class is really there just for compatibility with Java. deftype should be preferred.
Here's a project of mine where I create a custom type and data reader, if you want an example: https://github.com/weavejester/crumpets However, it feels like you're looking for a solution in the wrong place. I obviously don't know the precise problem you're trying to solve, so I may be completely wrong, but the example code you've shown so far seems a little odd. - James On 12 December 2013 16:34, Tim <tcr1...@gmail.com> wrote: > And that's ok, there's obviously more to it and not knowing or > understanding the spec I wouldn't expect you to make sense of that piece. > Still, the question really is: If you were to do this, would you implement > deftype, gen-class instead? Would the hacked approach be a bad idea and if > so for what reason? Staying within the bounds of the question are there > other approaches to doing the same thing? I initially just wanted to use > with-meta that could attach to any data, but obviously with-meta limits > what it can be attached to which led to the above approach. > > Thanks, > > On Thursday, December 12, 2013 10:43:22 AM UTC-5, James Reeves wrote: > >> Why not something like: >> >> {:where [[:id 'identity]] :sort [[:id :desc]]} >> >> That would make it relatively straightforward to merge queries (use >> `into` and then check for duplicates in :sort). >> >> To me, it doesn't make a huge amount of sense to tie sorting logic onto >> the field itself. >> >> - James >> >> >> On 12 December 2013 13:56, Tim <tcr...@gmail.com> wrote: >> >>> 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> 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 >>>>> >>>>> 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 >>>>> >>>>> 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. >>>>> >>>>> 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.
