5. If you need a concrete class definition that then implements a set of type specific interfaces this would seem to fall into a category of gen-class assuming you could specify the interfaces with type specifications. I can't immediately place a way to do this with anything mentioned above. It may be then important to be able to override Object methods but maybe you already can with gen-class.
On Tue, Jul 2, 2019 at 7:24 PM Chris Nuernberger <ch...@techascent.com> wrote: > eglue, > > 1. I think this is a great idea if it is really necessary. I would be in > favor of a reify++ alone to simplify things. I find reify amazing at code > compression and heavily use it via type specific macros to implement > interfaces that for instance support a particular primitive type. > 2. Is a possible workaround to define java interfaces that implement the > type specific generic interfaces and then reify those explicitly or is the > set of possible interface specialization types unknown a-priori? > 3. The case where something is unbounded or unknown a-priori I would > think would often end up with a java class as on of the specializations. > In this case, regardless of the cause, one answer might be an upgraded > reify pathway. > 4. Are these perhaps cases where you can create just a little bit of java > as a generator somehow to generate the interface you need to reify? > > > I would personally find reify a much nicer pathway than calling clojure > vars from java. > > I also think there could be low hanging fruit (or just good unknown > libraries) in the pathway for calling clojure vars from java. > > > Interesting problem (at least to me), thanks! > > On Thu, Jun 20, 2019 at 10:03 PM eglue <atdi...@gmail.com> wrote: > >> 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 >> <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/CADbpEJtvHw7QovPAwCZwfrvopq8aEfpZ7LhLeobfKt%3DEh7vL6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
