Let's say I have a proxy object:
(def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
Now, I want to call (.interfaceMethod p). How do I do this without
reflection?
I would have thought that (.interfaceMethod ^MyInterface p) would work, but
this results in an error message that thi
That's exactly what you should do and it does work, e.g.:
user=> (set! *warn-on-reflection* true)
true
user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] {:a
1})))
{:a 1}
In your small example you have two errors that might be fishy: a missing arg
vector to pass to the su
Those fishy things were errors I made when simplifying and transcribing the
proxy to post, but I have it correct in my own code.
Here's a more precise, tested minimal example:
(definterface Interface (test []))
(def p (proxy [Object Interface] [] (test [] 1)))
(defn get-test [o] (.test ^Interface
Which version of clojure? This works fine in 1.10
Clojure 1.10.0-master-SNAPSHOT
user=> (set! *warn-on-reflection* true)
true
user=> (definterface Interface (test []))
user.Interface
user=> (def p (proxy [Object Interface] [] (test [] 1)))
#'user/p
user=> (defn get-test [o] (.test ^Interface o))
#
I'm using 1.9.0. Is this a behavior that recently changed?
On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto wrote:
> Which version of clojure? This works fine in 1.10
>
> Clojure 1.10.0-master-SNAPSHOT
> user=> (set! *warn-on-reflection* true)
> true
> user=> (definterface Interface (test []))
>
No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
expect.
Are you testing this in a fresh environment?
> On 30 Jul 2018, at 11:31, Mark Engelberg wrote:
>
> I'm using 1.9.0. Is this a behavior that recently changed?
>
> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto
Yes, it is in a fresh environment.
I find that the problematic example *does* work in the user namespace, but
it doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be
really specific).
On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto wrote:
> No, I just tested this on 1.9.0 an
Can you paste an entire repl session, starting from how you launch it (e.g.
lein repl vs clj -- ideally not from a project) reproducing this?
I'm interested in taking a look but I simply cannot repro :/
> On 30 Jul 2018, at 11:40, Mark Engelberg wrote:
>
> Yes, it is in a fresh environment.
>
OK, I just pushed the repo (work in progress) to github.
https://github.com/Engelberg/mister-rogers
At the bottom of mister-rogers.wrappers I tacked on the three lines we've
been discussing.
https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rog
Ok, just taking a cursory look and what you're seeing might be related to
double-loading.
It might be that the fixes that went in around ~1.5/1.6 missed some edge-cases
related to `proxy`, I'll investigate more this evening
> On 30 Jul 2018, at 11:50, Mark Engelberg wrote:
>
> OK, I just push
If it’s run on CircleCI or Travis and has readonly access to github, I
wouldn’t be too concerned.
The most frequent downloads API in Clojars is a good idea. Could use it as
a basis for the hand rolled site for now and target it for automation in
the future. I’m wondering how amenable/suitable it w
Right, but the disadvantage is that you're releasing something that's now
incomplete on its own.
I'd've hoped that clojure wouldn't have become as tightly-coupled with spec
(for instance), but maybe I just need to read the Rationale page more
deeply. Dependency hell blows, especially if your wo
Nathan,
I wasn’t concerned with Github per se but the CI server compiling/running
arbitrary code should some library’s repo get pwnd in some way or that a
rogue library could make it into the list of repos to build in the proposed
system. A hand curated list of repos would mitigate this last conce
Right, but the disadvantage is that you're releasing something that's now
incomplete on its own.
Every non-trivial Clojure program has dependencies so you’re going to be using
either `clj`/`clojure` shell scripts and `deps.edn`, or else Leiningen or Boot.
And if you use any of those, the clojur
On 31 Jul 2018, at 9:08, Payter Versteegen wrote:
> I'd've hoped that clojure wouldn't have become as tightly-coupled with spec
> (for instance), but maybe I just need to read the Rationale page more deeply.
> Dependency hell blows, especially if your work environment is disconnected
> from the
That's one downside, ideally (in my world) spec would be a compile/test time
dependency - esp. since AFAIK it's not recommended to turn it on at run-time
for day-to-day operation.
We use clojure.spec extensively in production code so that certainly isn’t
true. You might not turn on instrumentat
16 matches
Mail list logo
