Sean, That is an interesting blog post. Sorry if I am not following everything but why not use the annotation support in gen-class for those types of things?
https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34 On Friday, June 21, 2019 at 1:29:56 PM UTC-6, Sean Corfield wrote: > > You might be interested in how we provide type-based annotations on > Clojure functions so that tooling (in our case New Relic) sees those > annotations: > > > > > https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/ > > > > I agree that this could be a lot easier. > > > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > ------------------------------ > *From:* clo...@googlegroups.com <javascript:> <clo...@googlegroups.com > <javascript:>> on behalf of eglue <atd...@gmail.com <javascript:>> > *Sent:* Thursday, June 20, 2019 9:03:45 PM > *To:* Clojure > *Subject:* Java Interop on steroids? > > 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 clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clo...@googlegroups.com <javascript:> > 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 clo...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/128dd732-b79e-4c35-999f-691cdc42512b%40googlegroups.com > > <https://groups.google.com/d/msgid/clojure/128dd732-b79e-4c35-999f-691cdc42512b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/beca47df-4227-4d08-a71f-0e98e34a7acf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
