Re: Monorepos with separate artifacts?
We have used a monorepo to produce multiple artifacts with lein as described here: http://david-mcneil.com/post/160191443293/using-lein-to-produce-multiple-artifacts-from-a -David -- 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/d/optout.
Re: [ANN] Clojure 1.7.0-beta2
I did a real quick test on one of our projects. I had to upgrade to the latest compojure (seems the old version used a version of instaparse that wouldn't compile) but after that it seemed to work and was noticably faster. -David -- 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/d/optout.
Re: Coding Standard - ns usage
I have not heard from anyone that http://dev.clojure.org/display/design/Library+Coding+Standards is out of date, so I take that to mean that the following is still the standard: Be explicit and minimalist about dependencies on other packages. (Prefer the :only option to use and require). -David -- 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
Coding Standard - ns usage
I notice the following item at http://dev.clojure.org/display/design/Library+Coding+Standards Be explicit and minimalist about dependencies on other packages. (Prefer the :only option to use and require). The page was last edited on Mar 29, 2011 and ns usage has been discussed a fair bit since then... this leads to the question: Is the item quoted above still the standard for Clojure Libraries? Thanks. -David -- 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
Re: Build Issues with Eclipse
Does this thread address your need? https://groups.google.com/forum/?fromgroups=#!searchin/clojure/local$20repository$20/clojure/1Ne8RqiffVI/aGoCPWiiCakJ -David -- 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
core.match - matching missing map values
I expected this to match, but it did not.
(clojure.core.match/match [{}]
[{:x (x :when nil?)}]
[match x])
;;= nil
Instead, I was able to make this work:
(clojure.core.match/match [{}]
[{:x (x :when #(= :clojure.core.match/not-found
%))}]
[match x])
;;= [match nil]
I am curious: is this by design?
Thanks.
-David McNeil
--
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
core.match - variable length match patterns
From what I can see core.match does not support matching a variable length series of values. For example, in a vector, match a series of 0-to-N values of 1 followed by a value of 2. I am interested to know whether/how match patterns like this would fit into core.match. Thank you. -David McNeil -- 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
Re: core.match - variable length match patterns
On Friday, May 18, 2012 9:59:40 AM UTC-5, David Nolen wrote: It sounds like you're describing searching for a pattern? Yes, I think that sounds right. I am not sure how that fits into the core.match picture. Thanks. -David McNeil -- 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
Re: Trickiness with protocols and extends (1.3.0)
A couple of more thoughts on this. On Oct 28, 12:46 pm, Howard Lewis Ship hls...@gmail.com wrote: (extend-type cascade.Asset ToAttributeValueString (to-attribute-value-string [asset] (:client-url asset))) The reason this is probably not what you really want is that the set of types which satisfy the Asset protocol is a superset of the set of types which satisfy the cascade.Asset interface. This is certainly not immediately obvious, but one way to understand it is that if you extend a built-in Java type to implement your protocol, it does not change the underlying type to implement the protocol's interface. Rather it provides machinery in the protocol itself that knows how to use the built-in Java type to satisfy the protocol. I don't think it is useful to try and think of this as interface inheritance because it is not the same as interface inheritance in Java. I wasn't used to thinking of it as inheritance, but after thinking about it more it seems like inheritance is a reasonable way to think of it. Adapting protocol A to protocol B is like saying that all types satisfying protocol B can also be used as if they satisfy protocol A and furthermore there is a default implementation (that can be over- ridden) of protocol A for them. -David -- 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
Re: Trickiness with protocols and extends (1.3.0)
On Oct 28, 12:46 pm, Howard Lewis Ship hls...@gmail.com wrote: (extend-type Asset ToAttributeValueString (to-attribute-value-string [asset] (:client-url asset))) As Alex mentioned we have an adapt-protocol macro [1] [2] that I think will do what you want. It would be invoked as: (adapt-protocol Asset ToAttributeValueString (to-attribute-value-string [asset] (client-url asset))) From your original code, I changed extend-type to adapt-protocol and I fixed what I think is a type by changing :client-url to client-url. There are different ways to think of what this does. One way is to think of adapting one protocol to another. The adapt-protocol call defines how to adapt an Asset object to an ToAttributeValueString object. Another way is to think of layering the protocols. The ToAttributeValueString protocol is layered on top of the Asset protocol by defining how to satisfy the ToAttributeValueString protocol in terms of the Asset protocol. At a lower level what this adapt-protocol call means is: for any type that implements Asset but does not already implement ToAttributeValueString, add an implementation of Asset to that type using the provided functions. This implementation will be added the first time that an attempt is made to access the type via the ToAttributeValueString protocol. It is useful to be able to define this in one place rather than tracking down all of the types that implement the Asset protocol and extending them to support the ToAttributeValueString protocol. I don't think it is useful to try and think of this as interface inheritance because it is not the same as interface inheritance in Java. We are using this code in production to do exactly what you described. The only real issue to be aware of is that once an adapter is “installed” for a class subsequent calls to adapt-protocol do not affect the class. This can cause pain at dev time when you are changing the adapter code and want to dynamically redefine an adapter. I talk about this issue and a way to address it at dev time in the blog post [1]. -David [1] http://david-mcneil.com/post/3495351254/clojure-protocol-adapters [2] https://github.com/david-mcneil/clojure-adapt -- 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
Re: metadata for records
Razvan Rotaru wrote:
Is there a way to attach metadata to defrecord ?
Is this what you are looking for?
(defrecord MyRecord [a b])
(let [r (with-meta (MyRecord. 1 2) {:extra 100})]
(meta r))
;;- {:extra 100}
-David
--
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
Revelytix hiring Clojure developers
Revelytix [1] is hiring Clojure developers for full-time, direct employment in St. Louis, Missouri and Baltimore, Maryland USA. We are a relatively small team of developers building semantic technology based, data integration products. We understand that applicants may not have deep Clojure or semantic technology experience, but this is a great place to get it! If you are interested, email a note and your resume to careers _at_ revelytix.com. [1] http://revelytix.com/ Thanks. -David McNeil -- 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
Re: Any ways to prevent protocol functions from being hardcoded in?
On Jun 30, 7:54 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: Recently the received wisdom has been: protocols are a low-level implementation detail. Actual APIs should be built with normal functions that call the protocol methods. Stuart- I am a bit confused by this statement, and judging by this thread others are as well. Any chance you could elaborate on the received wisdom with respect to protocols and APIs? Thank you. -David -- 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
Clojure 1.3 - Embedding Java literal objects
I noticed the following behavior in Clojure 1.3 related to the new
object literal syntax [1]:
Clojure 1.3.0-master-SNAPSHOT
user= (defrecord Foo [a b])
user.Foo
user= (:a #user.Foo{:a 1 :b 2})
1
user= #java.awt.Point[10 20]
#Point java.awt.Point[x=10,y=20]
user= (.getX #java.awt.Point[10 20])
CompilerException java.lang.RuntimeException: Can't embed object in
code, maybe print-dup not defined: java.awt.Point[x=10,y=20],
compiling:(NO_SOURCE_PATH:10)
It seems that the Java literal object syntax can be embedded in larger
expressions for records but not for plain Java objects?
Truly, I don't know whether this was intended to work or not but I
thought I would mention it since I came across it.
Thanks.
-David
[1] -
http://clojure02.managed.contegix.com/display/design/defrecord+improvements
--
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
Re: Idiomatic use of records vs. maps
A couple of aspects of records that I have found useful: * they provide a type for dispatching. Rather than rooting around in the map to find out what it is, a multi-method can dispatch directly on the type of the object. * having a central definition of the main keys contained in the structure is sometimes nice for defining an apps data structures -David -- 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
Re: partial vs anonymous function?
For those who duck it in the future, there is more discussion here: http://groups.google.com/group/clojure-dev/browse_thread/thread/f4907ebca8ef6e11 -David -- 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
Re: eval'ing records
For those who duck it in the future, there is more discussion here: http://groups.google.com/group/clojure-dev/browse_thread/thread/f4907ebca8ef6e11 -David -- 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
Re: def and ;dynamic
Thank you for your solution, but can you explain why it works ? As best I recall... in Clojure 1.3 vars are no longer dynamic by default. In the short-term, to ease the pain of this change, Clojure 1.3 will automatically make vars with earmuffs (e.g. *foo*) into dynamic variables. But it warns you so you can correct it and explicitly identify them as dynamic if you need them to be. -David -- 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
partial vs anonymous function?
I am puzzled by the results below. Can anyone explain the difference in behavior? -David (defn mapper [f stream] `(map ~f ~stream)) (eval (mapper #(+ 1 %) [10 11 12])) ;; - (11 12 13) (eval (mapper (partial + 1) [10 11 12])) ;; - No matching ctor found for class clojure.core$partial... -- 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
Re: partial vs anonymous function?
Mark - Thanks. I am able to permute it to make it work. However, I cannot explain why the original code fails. -David -- 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
eval'ing records
I have learned that instances of records do not eval to themselves.
This seems inconsistent to me. I am curious if this is intentional or
if it is a gap in the current record implementation in Clojure.
Thanks.
-David
(defn eval-type [x]
(class (eval x)))
;; instances of structural types evaluate to themselves
(eval-type {:a 100})
;; - clojure.lang.PersistentArrayMap
(eval-type [100])
;; - clojure.lang.PersistentVector
;; instances of java objects evaluate to themselves
(eval-type hello)
;; - java.lang.String
(eval-type (java.util.Date.))
;; - java.util.Date
(eval-type (java.util.Locale. en US))
;; - java.util.Locale
;; but instances of records...
(defrecord Foo [a])
(eval-type (Foo. 100))
;; - clojure.lang.PersistentArrayMap
;; .. evaluate to maps not instances of the record class?
--
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
Re: eval'ing records
I remember reading about it in the Joy of Clojure. It may be fixed in the future versions of Clojure. Ivan - Thanks for the response. I checked Joy of Clojure and I see a reference at the top of page 191 to the fact that records cannot be printed and then eval'd. I was aware of this, however the issue I identified in this discussion is that record instances _themselves_ do not eval to themselves. This is a bit different than printing them and eval'ing them. -David -- 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
Protocol functions higher order functions
The following code shows surprising behavior related to using protocol functions in higher order functions. I sort of understand the reason wrapped-x first fails is that calling extend-protocol in a sense redefines the x protocol function. I can't decide if I think this is a bug or just the way protocols work. I am curious what others think. -David (defprotocol Foo (x [this arg])) (defn wrap [f] (fn [ args] (apply f args))) (def wrapped-x (wrap x)) (extend-protocol Foo String (x [this arg] (str this arg))) (wrapped-x hello joe) ;; - No implementation of method: :x of protocol: #'user/Foo found for class: java.lang.String (def wrapped-x (wrap x)) (wrapped-x hello joe) ;; - hellojoe -- 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
Re: Protocol functions higher order functions
I think not a bug. If you want indirection in your wrapper, you can ask for it, e.g.: (defn wrap [f] (fn [ args] (apply @f args))) (def wrapped-x (wrap #'x)) Thank you! -David -- 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
Re: Struct vs. Record: Now and Future
While this serialization has been fine for most of my needs I have quite often wanted to be able to use *print-dup* since binary serialization seemed overkill in those cases. Hopefully something like defrecord2 gets added to clojure at some point to make dealing with records more pleasant. This is a snapshot of a defrecord2 implementation that I have been using. Among other things it makes records print in an eval'able form. https://github.com/david-mcneil/defrecord2 -David -- 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
Re: Reading back record instances
I discuss one solution to this problem here: http://david-mcneil.com/post/958196603/enhanced-clojure-records-part-2 -David -- 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
Re: disk-backed memoize?
http://github.com/alienscience/cache-dot-clj Thanks for the link. That is helpful. Would JDBC suit your needs as a storage medium? I suppose that would work, but I am thinking that an ehcache based plugin for cache-dot-clj might be a good solution. -David -- 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
Re: Protocol type hints - Java interface
David - Thanks for the tips on definterface and the new statics feature. I will need to look into these because I am not familiar with either. What is the difference between gen-interface and definterface? Thanks. -David McNeil -- 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
Re: Destructuring namespace qualified map keys
(let [{x :x/y} {:x/y 20}] x)
20
That will work. Thank you!
-David McNeil
--
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
Cyclical refs fail on Clojure 1.2?
(def a (ref ())) (def b (ref ())) (dosync (alter a conj b)) (dosync (alter b conj a)) This last expression fails with an Evalutation aborted message on Clojure 1.2.0-master-SNAPSHOT (it works on Clojure 1.1.0). Maybe I am not using refs correctly, but I did not expect this to fail. Can anyone explain this? Thank you. -David McNeil -- 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
Re: Cyclical refs fail on Clojure 1.2?
Peter- Thanks for the tip. I was aware of the stack overflow issue you described, but your comment motivated me to switch to using mvn clojure:repl instead of mvn clojure:swank to test the code, and this does appear to work (modulo the REPL printing issue). Thank you. -David McNeil -- 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
ClojureQL - joining 3 tables
In ClojureQL I do not see how to join three or more tables using the join function. Does anyone know if this is possible? Thank you. -David McNeil -- 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
Defining a namespace inside a let
I am experimenting with clojure.test and I encountered the following
situation which I cannot explain.
This code:
(println (do
(ns ns01
(:use clojure.test))
(deftest test1 nil)
(run-tests)))
Produces the expected result (note: it runs one test):
Testing ns01
Ran 1 tests containing 0 assertions.
0 failures, 0 errors.
{:type :summary, :test 1, :pass 0, :fail 0, :error 0}
However, if I do the exact same thing inside of a let:
(println (let []
(do
(ns ns02
(:use clojure.test))
(deftest test1 nil)
(run-tests
Then I get the unexpected result that no tests are executed:
Testing ns02
Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
{:type :summary, :test 0, :pass 0, :fail 0, :error 0}
Seems there is something going on with namespaces that I do not
understand and I hope that somewhere here can explain it.
Thank you.
-David McNeil
--
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
Re: Extending Java class in Clojure with multiple constructors
Stephan- Thank you, gen-class is what I needed. -David -- 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
Extending Java class in Clojure with multiple constructors
When extending a Java class in Clojure, what is a clean way to support
multiple constructors in the base class? Below is a sample of how I
accomplished this. The key point is that the base class has two
constructors and to expose both of these in Clojure I needed to create
two proxies. I used a macro to avoid duplicating the proxy definition.
My question is: is there a better way to accomplish this, perhaps
using a mechanism other than proxy?
Thank you.
-David McNeil
Person.java
=
package demo;
public class Person {
private int id = 0;
private String name;
public Person( int id ) {
this.id = id;
}
public Person( int id, String name ) {
this.id = id;
this.name = name;
}
public String toString() {
return Person id= + id + name= + name;
}
}
demo.clj
(ns clojure-proxy.demo
(:import (demo Person)))
(defmacro sub-person [ args]
`(proxy [Person] [...@args]
(toString [] (str overridden toString
(defn to-person
([id]
(sub-person id))
([id name]
(sub-person id name)))
(.toString (to-person 15 joe))
(.toString (to-person 20))
--
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
