search

redplanetlabs / proxy-plus

A replacement for Clojure's proxy that's 10x faster and more usable
Apache License 2.0
175 stars 10 forks source link

Support for proxy-super equivalent #17

Open samharad opened 1 year ago

samharad commented 1 year ago

Would be nice to have an equivalent to Clojure's proxy-super. May or may not be possible to do efficiently. One idea is to wrap the call to super in a lambda and make the lambda available to the clojure body code via a binding.

owenRiddy commented 1 year ago

Implementing proxy-super properly seems a bit hard. I couldn't figure out how to detect whether the code is in a context where it is usually legal to call the superclass or not.

I've implemented a horrible hack while we wait for competent people to puzzle that one out. https://github.com/owenRiddy/proxy-plus-minus implements a proxy-super+ by automatically exposing the superclass' methods to everyone and hoping that people behave responsibly and/or don't consider such an audacious scheme and only put proxy-super+ in sensible places. This implementation should avoid https://clojure.atlassian.net/browse/CLJ-2201 and be usable in situations where thread safety is important.

I won't ask for my work to be pulled into proxy-plus because I consider my efforts an affront to good software engineering and live in hope that someone will think of a better way.

nathanmarz commented 1 year ago

That's clever. Definitely too much of a hack to pull it in though. I think doing this properly would ultimately require support from the Clojure compiler.

owenRiddy commented 1 year ago

I think doing this properly would ultimately require support from the Clojure compiler.

It'd be helpful. Although after spending 24 hours mulling I'm not sure even access to the compiler is enough to get to an elegant proxy-super+ so I'm not holding my breath.

We're up against a really awkward crack in the design. Clojure functions are independent of the object that represents the proxy - therefore any attempt to replicate the behaviour of Java's super will lead to weirdness because at the technical level there has to be a mechanism for one object to reach out and call another object's shadowed methods. Any restrictions on that are arbitrary.

Seems to me we need new semantics of what is reasonably allowed access to superclass methods (only lexically in the proxy+? functions 1 deep in the call stack? Functions in the same namespace as the call to proxy+? On the thread between when a proxied method starts and ends executon? Everything, everywhere all at once?).

Case closed for the moment I suppose.