Re: Java method call irritation

2010-03-19 Thread Laurent PETIT
Hi, In this particular case, his get-properties macros was a demonstration of how to write a macro, but could have been replaced with an out-of-the-box clojure.core/bean call. 2010/3/19 Per Vognsen per.vogn...@gmail.com: My experience as a newcomer to Clojure is that one of the most surprising

Re: Java method call irritation

2010-03-19 Thread Konrad Hinsen
On 18 Mar 2010, at 16:55, Per Vognsen wrote: Is there any reason why a .method occurrence in non-operator position doesn't just do the closure wrapping automagically? There is two reasons I can think of, though of course I can't know if they are the real ones. First, a technical reason:

Re: Java method call irritation

2010-03-19 Thread Per Vognsen
On Fri, Mar 19, 2010 at 2:46 PM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 18 Mar 2010, at 16:55, Per Vognsen wrote: Is there any reason why a .method occurrence in non-operator position doesn't just do the closure wrapping automagically? There is two reasons I can think of, though

Re: Java method call irritation

2010-03-19 Thread LauJensen
Konrad, Im not following where this would be a problem in terms of optimization. In the definition for map, all that needs to be added is a check for a symbol? and the resulting sequence could look and act exactly like it would, had you manually added the #(.method %) right? If the technical

Re: Java method call irritation

2010-03-19 Thread Per Vognsen
I don't think passing symbols around and having special case behavior scattered around different functions is going to help beginners. If anything, it would confuse them when they try to treat .methods as first-class functions in their own code and discover that it doesn't work. -Per On Fri, Mar

Re: Java method call irritation

2010-03-19 Thread Laurent PETIT
Where would you place the type hint needed to avoid reflection ? 2010/3/19 LauJensen lau.jen...@bestinclass.dk: Konrad, Im not following where this would be a problem in terms of optimization. In the definition for map, all that needs to be added is a check for a symbol? and the resulting

Re: Java method call irritation

2010-03-19 Thread Chouser
On Fri, Mar 19, 2010 at 4:04 AM, Per Vognsen per.vogn...@gmail.com wrote: On Fri, Mar 19, 2010 at 2:46 PM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 18 Mar 2010, at 16:55, Per Vognsen wrote: Is there any reason why a .method occurrence in non-operator position doesn't just do the

Re: Java method call irritation

2010-03-19 Thread Stuart Sierra
On Mar 18, 11:55 am, Per Vognsen per.vogn...@gmail.com wrote: Is there any reason why a .method occurrence in non-operator position doesn't just do the closure wrapping automagically? It's been discussed as a possibility; it may be added to Clojure in the future. -SS -- You received this

Java method call irritation

2010-03-18 Thread alux
Hello, I just was to lazy to get my Javadoc, so I wanted to list the methods of an object from the 1.1-REPL. I got different results when mapping .getName or #(.getName %) over the seq I produced - I expected this to be the same. So seemingly my expectations are wrong. Would you please rectify?

Re: Java method call irritation

2010-03-18 Thread Meikel Brandmeyer
Hi, Java methods are not clojure functions. To treat them like first-class functions you have to wrap them in clojure functions as you did in your second example. For your actual task: you might want to look at clojure.contrib.repl- utils/show. Sincerely Meikel -- You received this message

Re: Java method call irritation

2010-03-18 Thread alux
Thank you Meikel. I just didnt encounter that information before ;-) I'm still in the process of learning the core lib, so while learning I sometimes avoid the contrib libraries, and try myself. Here this proved educating again ;-) (wouldn't do so for production ;-) Thank you and regards, alux

Re: Java method call irritation

2010-03-18 Thread Stuart Halloway
memfn is from the depths of time and should be deprecated -- it is idiomatic to write an anonymous fn around the method. Stu This seems like a potential usecase for (memfn): - clojure.core/memfn ([name args]) Macro Expands into code that creates a fn that expects

Re: Java method call irritation

2010-03-18 Thread Per Vognsen
Is there any reason why a .method occurrence in non-operator position doesn't just do the closure wrapping automagically? -Per On Thu, Mar 18, 2010 at 9:50 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: memfn is from the depths of time and should be deprecated -- it is idiomatic to write

Re: Java method call irritation

2010-03-18 Thread Seth
Would :deprecated be a reasonable thing to include in a function's metadata? Just the presence of it seems good enough, but I guess pairing it with some programmer friendly message (hey, use bar instead of foo) might be nice. Or... maybe 10,000 lines of XML as metadata! :-) On Mar 18, 10:50 am,

Re: Java method call irritation

2010-03-18 Thread Sean Devlin
And upgrade the doc macro accordingly? That would make entirely too much sense. +1 On Mar 18, 2:36 pm, Seth seth.schroe...@gmail.com wrote: Would :deprecated be a reasonable thing to include in a function's metadata? Just the presence of it seems good enough, but I guess pairing it with some

Re: Java method call irritation

2010-03-18 Thread Michael Gardner
On Mar 18, 2010, at 10:55 AM, Per Vognsen wrote: Is there any reason why a .method occurrence in non-operator position doesn't just do the closure wrapping automagically? I'd like to know this as well. Smooth Java interop is one of Clojure's selling points, but having to wrap Java methods in

Re: Java method call irritation

2010-03-18 Thread Per Vognsen
My experience as a newcomer to Clojure is that one of the most surprising things is the dichotomy between the Clojure and JVM world. I was reading one of Lau's blog posts on converting images to ASCII art: http://www.bestinclass.dk/index.php/2010/02/my-tribute-to-steve-ballmer His