On Mar 18, 11: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?
It's been discussed as a possibility; it may be added to Clojure in
the future.
-SS
--
You received this message because you are
On Fri, Mar 19, 2010 at 4:04 AM, Per Vognsen wrote:
> On Fri, Mar 19, 2010 at 2:46 PM, Konrad Hinsen
> 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?
>>
>>
Where would you place the type hint needed to avoid reflection ?
2010/3/19 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 a
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
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 obst
On Fri, Mar 19, 2010 at 2:46 PM, Konrad Hinsen
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 of course I can't k
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: .m
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 :
> My experience as a newcomer to Clojure is that one of the most
> surprising things is the dicho
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 get-properties
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
And upgrade the doc macro accordingly? That would make entirely too
much sense.
+1
On Mar 18, 2:36 pm, Seth 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 programmer friendly m
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,
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
wrote:
> memfn is from the depths of time and should be deprecated -- it is idiomatic
> to write an anonymous fn around
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 t
This seems like a potential usecase for (memfn):
-
clojure.core/memfn
([name & args])
Macro
Expands into code that creates a fn that expects to be passed an
object and any args and calls the named instance method on the
object passing the args. Use when you want to tr
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
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 bec
17 matches
Mail list logo
