Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶ 
̶H̶i̶c̶k̶e̶y̶  guy.
However -- there are many popular Java frameworks that love to reflect on 
their annotations and their generic type signatures.

To name a heavyweight: Spring. But also, of late: big data frameworks, many 
written in Java, love reflecting on generic type signatures. My org is 
looking at Beam and Flink, for example.

These frameworks use types not for the static checking really but as 
parameters governing their own dynamic behavior. For example, Spring will 
use types at runtime to simply match objects to where they should be 
dynamically injected. Beam will look at your type signatures and do runtime 
validations to ensure it can process things appropriately. Of course this 
is unfortunate, using types this way, when it is all really just data. 
Clojure does -- or would do -- it better, simpler, directer, and all of 
that.

Yet we would like to leverage these frameworks. Or rather, we must for 
various pragmatic and business reasons.

And any time we need to "communicate" to these frameworks "through" their 
desired fashion of generic types and annotations, we can, of course, create 
the appropriate .java files to represent what is needed (and then do the 
invocation back to Clojure via IFn.invoke or Compiler.eval, etc). Yes, this 
works.

However this is quite tedious because in these frameworks I mentioned you 
end up having to create these Java files quite a bit. For example, when 
expressing a streaming data pipeline to Beam, you may specify multiple 
transforms, each a function with its own type signature.

A little searching and it seems Clojure has shied away from generating 
generic type information in places where it could offer this capability. 

For example, in `proxy` ... or I suppose also in `gen-class`, `reify`, and 
other dynamic bytecode generation features of Clojure.

However it seems to me that `proxy` (and these others) could allow one to 
pass in a representation of desired type arguments, annotations, etc. and 
then we could remain in Clojure to interop with these popular frameworks.

I respect Clojure's efforts to keep its core small and wait for worthy 
features to prove themselves.

So my question is not when is Clojure going to do this, but rather:

Are there any precedents in the community for someone building out the kind 
of richer Java interop that I'm nodding toward here?

For example, does anyone know of an attempt out there to build a `proxy` 
plus-plus, that would allow one to extend a generic class with provided 
type parameters and have this metadata properly rendered in the bytecode 
that proxy produces?

If not, as a practical and hopefully quick and workable solution, I was 
thinking it'd be possible to take the bytecode emitted by proxy and re-run 
it through ASM to create a *new* class with simply the proxy-produced class 
bytes filled-in with the desired, provided type parameters. I bet this 
could be sufficient and fast, with the slight overhead of the extra class.

To do this, I think I'd need access to these proxy-made bytes... either by 
having proxy answer them somehow, or offering a hook to contribute to the 
defined bytecode before it is committed to the classloader, or by having 
DynamicClassLoader have these bytes on hand for inquiring parties, or 
something else along these lines. This would likely be something that 
Clojure core would have to expose .. correct me if I'm wrong.

Would love to hear any other immediate thoughts on this.

I think once you realize that this generic type information is not even 
being used for "static typing" by these frameworks but rather as an (albeit 
poor) means to receive semantic information from their clients (as 
parameters to govern their own dynamic behavior), then the need/value of 
being able to remain in Clojure and communicate to these libraries through 
generic params and annotations perhaps becomes more understandable..









-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/128dd732-b79e-4c35-999f-691cdc42512b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to