Re: Annotations on gen-class :state
That was what I figured. However Clojure currently makes certain kinds of interop extremely painful, which makes it hard to integrate into existing frameworks. I'm not proposing anything that would encourage concrete derivation in pure Clojure programs, but I think that facilitating that interop is a worthwhile goal, especially since it's an explicit design goal of Clojure to expose the host where it's pragmatic to do so. Don't make me maintain a fork :-) On 16 April 2014 00:48, Alex Miller wrote: > I think not too favorably. :) See http://clojure.org/datatypes where > Rich says "concrete derivation is bad." I do not think he would be > interested in adding anything to Clojure that included concrete derivation. > > -- > 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. > 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. For more options, visit https://groups.google.com/d/optout.
Re: Annotations on gen-class :state
I think not too favorably. :) See http://clojure.org/datatypes where Rich says "concrete derivation is bad." I do not think he would be interested in adding anything to Clojure that included concrete derivation. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Annotations on gen-class :state
Alex, what's your feeling about how a reify-like form and a deftype-like form that supported concrete class extension (as detailed in the other thread) would be received? If you think there might be interest I can start a proposal and possibly write the patch as well. On 15 April 2014 14:32, Alex Miller wrote: > It is a non-goal for gen-class (and reify, proxy, etc)to support the > construction of any possible Java class or to fully support every possible > Java feature. That said, particular extensions to existing features might > be useful in reasonable use cases. > > > On Monday, April 14, 2014 7:56:21 PM UTC-5, Colin Fleming wrote: > >> Well, I'm a bit torn on this one. On the one hand, I'd love to have >> something that meets my particular use case (of course!) which I wrote >> about here: https://groups.google.com/d/topic/clojure/MznBwxZt4cY/ >> discussion. I think that case can be met while still keeping the API >> fairly simple. But once you start down the path of being able to do >> everything that you can in Java (multiple constructors, classes or members >> with non-standard visibility, annotations etc) the API becomes much more >> complicated, and I'm not sure where the right trade-off is there. My gut >> feeling is that much more than an extend-type as discussed in that thread >> should probably be done in Java, but again, maybe I just want what I >> personally need! >> >> >> On 15 April 2014 02:31, Jon Seltzer wrote: >> >>> This is unfortunate. I certainly can write a Java class and I expected >>> that would be the answer. The question for me is whether, as a group, we >>> see any value in having a consistent interface with the JVM. One could >>> argue that Clojure does not need any of the interop features it already >>> has. In fact, one might argue that all interop should occur by invoking >>> pure Clojure from Java only but I hope most of us would agree that would >>> not a very satisfying outcome. The Clojure in Clojure work being done >>> gives me hope this is going to change. A Clojure compiler written in >>> Clojure would almost certainly need to be full (or more fully) featured. >>> >>> I like Stuart Sierra's quote (Twitter): "Using Java libraries is >>> idiomatic Clojure", and this is true for a lot of us using Clojure. >>> >>> jbs >>> >>> >>> On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote: >>> gen-class really isn't suitable for doing complicated interop like annotating fields. It's heavily oriented towards a single means of managing state, which is a single field generally containing an atom, which in turn contains your actual state in a map or similar. If you really need multiple fields you can use deftype/defrecord, but they come with different restrictions - no inheritance, don't require their namespace on class init which is required for many use cases where you might want field annotations. I'm also not sure if their fields can be annotated. In general when you start needing that level of interop, the easiest thing is just to write a Java class and call into Clojure from there as required. On 14 April 2014 14:28, Jon Seltzer wrote: > There are many Java APIs that expect client APIs to annotate fields > but Clojure does not support annotations on fields. Is there any plan to > add support? > > And one tangential question: Is there any consideration of adding > gen-class support for multiple fields instead of just one? > > jbs > > -- > 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 > > Note that posts from new members are moderated - please be patient > with your first post. > To unsubscribe from this group, send email to > clojure+u...@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+u...@googlegroups.com. > > 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 clo...@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+u...@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
Re: Annotations on gen-class :state
It is a non-goal for gen-class (and reify, proxy, etc)to support the construction of any possible Java class or to fully support every possible Java feature. That said, particular extensions to existing features might be useful in reasonable use cases. On Monday, April 14, 2014 7:56:21 PM UTC-5, Colin Fleming wrote: > > Well, I'm a bit torn on this one. On the one hand, I'd love to have > something that meets my particular use case (of course!) which I wrote > about here: > https://groups.google.com/d/topic/clojure/MznBwxZt4cY/discussion. I think > that case can be met while still keeping the API fairly simple. But once > you start down the path of being able to do everything that you can in Java > (multiple constructors, classes or members with non-standard visibility, > annotations etc) the API becomes much more complicated, and I'm not sure > where the right trade-off is there. My gut feeling is that much more than > an extend-type as discussed in that thread should probably be done in Java, > but again, maybe I just want what I personally need! > > > On 15 April 2014 02:31, Jon Seltzer >wrote: > >> This is unfortunate. I certainly can write a Java class and I expected >> that would be the answer. The question for me is whether, as a group, we >> see any value in having a consistent interface with the JVM. One could >> argue that Clojure does not need any of the interop features it already >> has. In fact, one might argue that all interop should occur by invoking >> pure Clojure from Java only but I hope most of us would agree that would >> not a very satisfying outcome. The Clojure in Clojure work being done >> gives me hope this is going to change. A Clojure compiler written in >> Clojure would almost certainly need to be full (or more fully) featured. >> >> I like Stuart Sierra's quote (Twitter): "Using Java libraries is >> idiomatic Clojure", and this is true for a lot of us using Clojure. >> >> jbs >> >> >> On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote: >> >>> gen-class really isn't suitable for doing complicated interop like >>> annotating fields. It's heavily oriented towards a single means of managing >>> state, which is a single field generally containing an atom, which in turn >>> contains your actual state in a map or similar. If you really need multiple >>> fields you can use deftype/defrecord, but they come with different >>> restrictions - no inheritance, don't require their namespace on class init >>> which is required for many use cases where you might want field >>> annotations. I'm also not sure if their fields can be annotated. >>> >>> In general when you start needing that level of interop, the easiest >>> thing is just to write a Java class and call into Clojure from there as >>> required. >>> >>> >>> On 14 April 2014 14:28, Jon Seltzer wrote: >>> There are many Java APIs that expect client APIs to annotate fields but Clojure does not support annotations on fields. Is there any plan to add support? And one tangential question: Is there any consideration of adding gen-class support for multiple fields instead of just one? jbs -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@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+u...@googlegroups.com. 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 clo...@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+u...@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+u...@googlegroups.com . >> 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 fro
Re: Annotations on gen-class :state
Well, I'm a bit torn on this one. On the one hand, I'd love to have something that meets my particular use case (of course!) which I wrote about here: https://groups.google.com/d/topic/clojure/MznBwxZt4cY/discussion. I think that case can be met while still keeping the API fairly simple. But once you start down the path of being able to do everything that you can in Java (multiple constructors, classes or members with non-standard visibility, annotations etc) the API becomes much more complicated, and I'm not sure where the right trade-off is there. My gut feeling is that much more than an extend-type as discussed in that thread should probably be done in Java, but again, maybe I just want what I personally need! On 15 April 2014 02:31, Jon Seltzer wrote: > This is unfortunate. I certainly can write a Java class and I expected > that would be the answer. The question for me is whether, as a group, we > see any value in having a consistent interface with the JVM. One could > argue that Clojure does not need any of the interop features it already > has. In fact, one might argue that all interop should occur by invoking > pure Clojure from Java only but I hope most of us would agree that would > not a very satisfying outcome. The Clojure in Clojure work being done > gives me hope this is going to change. A Clojure compiler written in > Clojure would almost certainly need to be full (or more fully) featured. > > I like Stuart Sierra's quote (Twitter): "Using Java libraries is > idiomatic Clojure", and this is true for a lot of us using Clojure. > > jbs > > > On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote: > >> gen-class really isn't suitable for doing complicated interop like >> annotating fields. It's heavily oriented towards a single means of managing >> state, which is a single field generally containing an atom, which in turn >> contains your actual state in a map or similar. If you really need multiple >> fields you can use deftype/defrecord, but they come with different >> restrictions - no inheritance, don't require their namespace on class init >> which is required for many use cases where you might want field >> annotations. I'm also not sure if their fields can be annotated. >> >> In general when you start needing that level of interop, the easiest >> thing is just to write a Java class and call into Clojure from there as >> required. >> >> >> On 14 April 2014 14:28, Jon Seltzer wrote: >> >>> There are many Java APIs that expect client APIs to annotate fields >>> but Clojure does not support annotations on fields. Is there any plan to >>> add support? >>> >>> And one tangential question: Is there any consideration of adding >>> gen-class support for multiple fields instead of just one? >>> >>> jbs >>> >>> -- >>> 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 >>> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@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+u...@googlegroups.com. >>> >>> 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. > 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. For more options, visit https://groups.google.com/d/optout.
Re: Annotations on gen-class :state
This is unfortunate. I certainly can write a Java class and I expected that would be the answer. The question for me is whether, as a group, we see any value in having a consistent interface with the JVM. One could argue that Clojure does not need any of the interop features it already has. In fact, one might argue that all interop should occur by invoking pure Clojure from Java only but I hope most of us would agree that would not a very satisfying outcome. The Clojure in Clojure work being done gives me hope this is going to change. A Clojure compiler written in Clojure would almost certainly need to be full (or more fully) featured. I like Stuart Sierra's quote (Twitter): "Using Java libraries is idiomatic Clojure", and this is true for a lot of us using Clojure. jbs On Monday, April 14, 2014 1:10:47 AM UTC-7, Colin Fleming wrote: > gen-class really isn't suitable for doing complicated interop like > annotating fields. It's heavily oriented towards a single means of managing > state, which is a single field generally containing an atom, which in turn > contains your actual state in a map or similar. If you really need multiple > fields you can use deftype/defrecord, but they come with different > restrictions - no inheritance, don't require their namespace on class init > which is required for many use cases where you might want field > annotations. I'm also not sure if their fields can be annotated. > > In general when you start needing that level of interop, the easiest thing > is just to write a Java class and call into Clojure from there as required. > > > On 14 April 2014 14:28, Jon Seltzer >wrote: > >> There are many Java APIs that expect client APIs to annotate fields but >> Clojure does not support annotations on fields. Is there any plan to add >> support? >> >> And one tangential question: Is there any consideration of adding >> gen-class support for multiple fields instead of just one? >> >> jbs >> >> -- >> 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 >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@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+u...@googlegroups.com . >> 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. For more options, visit https://groups.google.com/d/optout.
Re: Annotations on gen-class :state
gen-class really isn't suitable for doing complicated interop like annotating fields. It's heavily oriented towards a single means of managing state, which is a single field generally containing an atom, which in turn contains your actual state in a map or similar. If you really need multiple fields you can use deftype/defrecord, but they come with different restrictions - no inheritance, don't require their namespace on class init which is required for many use cases where you might want field annotations. I'm also not sure if their fields can be annotated. In general when you start needing that level of interop, the easiest thing is just to write a Java class and call into Clojure from there as required. On 14 April 2014 14:28, Jon Seltzer wrote: > There are many Java APIs that expect client APIs to annotate fields but > Clojure does not support annotations on fields. Is there any plan to add > support? > > And one tangential question: Is there any consideration of adding > gen-class support for multiple fields instead of just one? > > jbs > > -- > 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. > 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. For more options, visit https://groups.google.com/d/optout.
Annotations on gen-class :state
There are many Java APIs that expect client APIs to annotate fields but Clojure does not support annotations on fields. Is there any plan to add support? And one tangential question: Is there any consideration of adding gen-class support for multiple fields instead of just one? jbs -- 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. For more options, visit https://groups.google.com/d/optout.
