Re: Oxford (UK) Clojure Group
Hi, Just a quick update, we haven't planned a meeting yet but I'm hoping to start one soon. For the moment you can join me on http://slack.digitaloxford.com/ in the #clojure channel, and I'm also on the http://clojurians.net if you are interested to keep in touch. Thanks, Kevin On Tuesday, 15 September 2015 22:04:49 UTC+1, Kévin Etienne wrote: > > Hi, > > I've seen a previous thread > https://groups.google.com/forum/#!topic/clojure/dRPF8bEpjBE > where a Clojure group in Oxford was mentioned. I don't know what happened > to Oxjure but > I'm interested in running a group and meeting people around Clojure and > more extensively > LISP. I've been to a Clojure in London and really enjoyed a few years ago. > > Let me know if you're around and if want to meet. At the moment I'm trying > to see if there's > enough traction and see what we can do. > > Thanks, > Kevin > -- 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.
Is java.lang.Class not a dependable map key?
I'm encountering a very strange error in some tests. The details are a bit complex, but I'm using type-indexed maps. So, given an object o, the map would be {(type o) o}. When I try to lookup with the key (type o), I don't get the value, even though I can clearly see it in the map. I have a map instance called new-still in my tests, and I can clearly see that this is its value {specs.core_test.Position {:x 0, :y 0}} However, when I try to compare the first key to the Position class (which it should be), I get this: Fail in run-systems-tst expected: (= (first (keys new-still)) Position) actual: (not (= specs.core_test.Position specs.core_test.Position)) How is it that the class specs.core_test.Position is not equal to itself?? Is this a bug, or just some quirk of compilation? Thanks. -- 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: Is java.lang.Class not a dependable map key?
When you reload a namespace with a record, the class for that record gets recreated. It will be functionally equivalent, but a different object. I'll bet that classes hash on identity. (Though if they hashed on name, you'd still have this problem.) On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: > I'm encountering a very strange error in some tests. > > The details are a bit complex, but I'm using type-indexed maps. > > So, given an object o, the map would be {(type o) o}. When I try to > lookup with the key (type o), I don't get the value, even though I can > clearly see it in the map. > > > I have a map instance called new-still in my tests, and I can clearly see > that this is its value > > {specs.core_test.Position {:x 0, :y 0}} > > > However, when I try to compare the first key to the Position class (which > it should be), I get this: > > > Fail in run-systems-tst > expected: (= (first (keys new-still)) Position) > actual: (not (= specs.core_test.Position specs.core_test.Position)) > > > > How is it that the class specs.core_test.Position is not equal to itself?? > Is this a bug, or just some quirk of compilation? > > Thanks. > > -- > 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: Is java.lang.Class not a dependable map key?
I suspected as much. It would be possible to mitigate the problem by not using the repl, but I want the library I'm making to be built around a repl-oriented workflow (like every good clojure library should). Is there any way around this, or do I have to resort to :type metadata? On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: > > When you reload a namespace with a record, the class for that record gets > recreated. It will be functionally equivalent, but a different object. > I'll bet that classes hash on identity. (Though if they hashed on name, > you'd still have this problem.) > > On Wed, May 18, 2016 at 1:31 PM, JvJ > > wrote: > >> I'm encountering a very strange error in some tests. >> >> The details are a bit complex, but I'm using type-indexed maps. >> >> So, given an object o, the map would be {(type o) o}. When I try to >> lookup with the key (type o), I don't get the value, even though I can >> clearly see it in the map. >> >> >> I have a map instance called new-still in my tests, and I can clearly see >> that this is its value >> >> {specs.core_test.Position {:x 0, :y 0}} >> >> >> However, when I try to compare the first key to the Position class (which >> it should be), I get this: >> >> >> Fail in run-systems-tst >> expected: (= (first (keys new-still)) Position) >> actual: (not (= specs.core_test.Position specs.core_test.Position)) >> >> >> >> How is it that the class specs.core_test.Position is not equal to itself?? >> Is this a bug, or just some quirk of compilation? >> >> Thanks. >> >> -- >> 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: Is java.lang.Class not a dependable map key?
I don't think there's a general workaround, and I'm not sure I have enough context to know what you are doing specifically. On Wed, May 18, 2016 at 2:28 PM, JvJ wrote: > I suspected as much. It would be possible to mitigate the problem by not > using the repl, but I want the library I'm making to be built around a > repl-oriented workflow (like every good clojure library should). > > Is there any way around this, or do I have to resort to :type metadata? > > On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: >> >> When you reload a namespace with a record, the class for that record gets >> recreated. It will be functionally equivalent, but a different object. >> I'll bet that classes hash on identity. (Though if they hashed on name, >> you'd still have this problem.) >> >> On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: >> >>> I'm encountering a very strange error in some tests. >>> >>> The details are a bit complex, but I'm using type-indexed maps. >>> >>> So, given an object o, the map would be {(type o) o}. When I try to >>> lookup with the key (type o), I don't get the value, even though I can >>> clearly see it in the map. >>> >>> >>> I have a map instance called new-still in my tests, and I can clearly >>> see that this is its value >>> >>> {specs.core_test.Position {:x 0, :y 0}} >>> >>> >>> However, when I try to compare the first key to the Position class >>> (which it should be), I get this: >>> >>> >>> Fail in run-systems-tst >>> expected: (= (first (keys new-still)) Position) >>> actual: (not (= specs.core_test.Position specs.core_test.Position)) >>> >>> >>> >>> How is it that the class specs.core_test.Position is not equal to >>> itself?? >>> Is this a bug, or just some quirk of compilation? >>> >>> Thanks. >>> >>> -- >>> 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: Is java.lang.Class not a dependable map key?
I'm creating an entity-component-system architecture. To use it, you define component types, and put a bunch of components in a map to make an entity. The rule for entities is that they can only have one component of any given type, so I figured I would use the class to index it. However, since this doesn't seem possible, I think I'll just make my own "defcomponent" macro which acts almost like defrecord, but makes sure that the constructor associates an appropriate keyword type tag in the metadata. Looking up the metadata is slightly slower than normal type reflection, but I doubt it will make much of a difference. On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote: > > I don't think there's a general workaround, and I'm not sure I have enough > context to know what you are doing specifically. > > On Wed, May 18, 2016 at 2:28 PM, JvJ > > wrote: > >> I suspected as much. It would be possible to mitigate the problem by not >> using the repl, but I want the library I'm making to be built around a >> repl-oriented workflow (like every good clojure library should). >> >> Is there any way around this, or do I have to resort to :type metadata? >> >> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: >>> >>> When you reload a namespace with a record, the class for that record >>> gets recreated. It will be functionally equivalent, but a different >>> object. I'll bet that classes hash on identity. (Though if they hashed on >>> name, you'd still have this problem.) >>> >>> On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: >>> I'm encountering a very strange error in some tests. The details are a bit complex, but I'm using type-indexed maps. So, given an object o, the map would be {(type o) o}. When I try to lookup with the key (type o), I don't get the value, even though I can clearly see it in the map. I have a map instance called new-still in my tests, and I can clearly see that this is its value {specs.core_test.Position {:x 0, :y 0}} However, when I try to compare the first key to the Position class (which it should be), I get this: Fail in run-systems-tst expected: (= (first (keys new-still)) Position) actual: (not (= specs.core_test.Position specs.core_test.Position)) How is it that the class specs.core_test.Position is not equal to itself?? Is this a bug, or just some quirk of compilation? Thanks. -- 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 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: Is java.lang.Class not a dependable map key?
Why not use the name of the class as the key? - James On 18 May 2016 at 20:02, JvJ wrote: > I'm creating an entity-component-system architecture. To use it, you > define component types, and put a bunch of components in a map to make an > entity. > > The rule for entities is that they can only have one component of any > given type, so I figured I would use the class to index it. However, since > this doesn't seem possible, > I think I'll just make my own "defcomponent" macro which acts almost like > defrecord, but makes sure that the constructor associates an appropriate > keyword type tag > in the metadata. > > Looking up the metadata is slightly slower than normal type reflection, > but I doubt it will make much of a difference. > > On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote: >> >> I don't think there's a general workaround, and I'm not sure I have >> enough context to know what you are doing specifically. >> >> On Wed, May 18, 2016 at 2:28 PM, JvJ wrote: >> >>> I suspected as much. It would be possible to mitigate the problem by >>> not using the repl, but I want the library I'm making to be built around a >>> repl-oriented workflow (like every good clojure library should). >>> >>> Is there any way around this, or do I have to resort to :type metadata? >>> >>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: When you reload a namespace with a record, the class for that record gets recreated. It will be functionally equivalent, but a different object. I'll bet that classes hash on identity. (Though if they hashed on name, you'd still have this problem.) On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: > I'm encountering a very strange error in some tests. > > The details are a bit complex, but I'm using type-indexed maps. > > So, given an object o, the map would be {(type o) o}. When I try to > lookup with the key (type o), I don't get the value, even though I can > clearly see it in the map. > > > I have a map instance called new-still in my tests, and I can clearly > see that this is its value > > {specs.core_test.Position {:x 0, :y 0}} > > > However, when I try to compare the first key to the Position class > (which it should be), I get this: > > > Fail in run-systems-tst > expected: (= (first (keys new-still)) Position) > actual: (not (= specs.core_test.Position specs.core_test.Position)) > > > > How is it that the class specs.core_test.Position is not equal to > itself?? > Is this a bug, or just some quirk of compilation? > > Thanks. > > -- > 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 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
Re: Is java.lang.Class not a dependable map key?
Or define components to have a member called (name-as-kw [this]) returning a keyword version of the name of the type. On Wed, May 18, 2016 at 1:31 PM, James Reeves wrote: > Why not use the name of the class as the key? > > - James > > On 18 May 2016 at 20:02, JvJ wrote: > >> I'm creating an entity-component-system architecture. To use it, you >> define component types, and put a bunch of components in a map to make an >> entity. >> >> The rule for entities is that they can only have one component of any >> given type, so I figured I would use the class to index it. However, since >> this doesn't seem possible, >> I think I'll just make my own "defcomponent" macro which acts almost like >> defrecord, but makes sure that the constructor associates an appropriate >> keyword type tag >> in the metadata. >> >> Looking up the metadata is slightly slower than normal type reflection, >> but I doubt it will make much of a difference. >> >> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote: >>> >>> I don't think there's a general workaround, and I'm not sure I have >>> enough context to know what you are doing specifically. >>> >>> On Wed, May 18, 2016 at 2:28 PM, JvJ wrote: >>> I suspected as much. It would be possible to mitigate the problem by not using the repl, but I want the library I'm making to be built around a repl-oriented workflow (like every good clojure library should). Is there any way around this, or do I have to resort to :type metadata? On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: > > When you reload a namespace with a record, the class for that record > gets recreated. It will be functionally equivalent, but a different > object. I'll bet that classes hash on identity. (Though if they hashed > on > name, you'd still have this problem.) > > On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: > >> I'm encountering a very strange error in some tests. >> >> The details are a bit complex, but I'm using type-indexed maps. >> >> So, given an object o, the map would be {(type o) o}. When I try to >> lookup with the key (type o), I don't get the value, even though I can >> clearly see it in the map. >> >> >> I have a map instance called new-still in my tests, and I can clearly >> see that this is its value >> >> {specs.core_test.Position {:x 0, :y 0}} >> >> >> However, when I try to compare the first key to the Position class >> (which it should be), I get this: >> >> >> Fail in run-systems-tst >> expected: (= (first (keys new-still)) Position) >> actual: (not (= specs.core_test.Position specs.core_test.Position)) >> >> >> >> How is it that the class specs.core_test.Position is not equal to >> itself?? >> Is this a bug, or just some quirk of compilation? >> >> Thanks. >> >> -- >> 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 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
Re: Is java.lang.Class not a dependable map key?
Will it be much better than type metadata, though? On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote: > > Or define components to have a member called (name-as-kw [this]) returning > a keyword version of the name of the type. > > On Wed, May 18, 2016 at 1:31 PM, James Reeves > wrote: > >> Why not use the name of the class as the key? >> >> - James >> >> On 18 May 2016 at 20:02, JvJ > wrote: >> >>> I'm creating an entity-component-system architecture. To use it, you >>> define component types, and put a bunch of components in a map to make an >>> entity. >>> >>> The rule for entities is that they can only have one component of any >>> given type, so I figured I would use the class to index it. However, since >>> this doesn't seem possible, >>> I think I'll just make my own "defcomponent" macro which acts almost >>> like defrecord, but makes sure that the constructor associates an >>> appropriate keyword type tag >>> in the metadata. >>> >>> Looking up the metadata is slightly slower than normal type reflection, >>> but I doubt it will make much of a difference. >>> >>> On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote: I don't think there's a general workaround, and I'm not sure I have enough context to know what you are doing specifically. On Wed, May 18, 2016 at 2:28 PM, JvJ wrote: > I suspected as much. It would be possible to mitigate the problem by > not using the repl, but I want the library I'm making to be built around > a > repl-oriented workflow (like every good clojure library should). > > Is there any way around this, or do I have to resort to :type metadata? > > On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: >> >> When you reload a namespace with a record, the class for that record >> gets recreated. It will be functionally equivalent, but a different >> object. I'll bet that classes hash on identity. (Though if they hashed >> on >> name, you'd still have this problem.) >> >> On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: >> >>> I'm encountering a very strange error in some tests. >>> >>> The details are a bit complex, but I'm using type-indexed maps. >>> >>> So, given an object o, the map would be {(type o) o}. When I try to >>> lookup with the key (type o), I don't get the value, even though I can >>> clearly see it in the map. >>> >>> >>> I have a map instance called new-still in my tests, and I can >>> clearly see that this is its value >>> >>> {specs.core_test.Position {:x 0, :y 0}} >>> >>> >>> However, when I try to compare the first key to the Position class >>> (which it should be), I get this: >>> >>> >>> Fail in run-systems-tst >>> expected: (= (first (keys new-still)) Position) >>> actual: (not (= specs.core_test.Position specs.core_test.Position)) >>> >>> >>> >>> How is it that the class specs.core_test.Position is not equal to >>> itself?? >>> Is this a bug, or just some quirk of compilation? >>> >>> Thanks. >>> >>> -- >>> 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 clo...@googlegroups.com >>> >>> Note that posts from new members are
Re: Is java.lang.Class not a dependable map key?
Well, if you store it in metadata you'll have to look it up in the metadata which is a hashmap lookup. As a method on a class it's a method call that returns a constant. On Wed, May 18, 2016 at 3:12 PM, JvJ wrote: > Will it be much better than type metadata, though? > > On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote: >> >> Or define components to have a member called (name-as-kw [this]) >> returning a keyword version of the name of the type. >> >> On Wed, May 18, 2016 at 1:31 PM, James Reeves >> wrote: >> >>> Why not use the name of the class as the key? >>> >>> - James >>> >>> On 18 May 2016 at 20:02, JvJ wrote: >>> I'm creating an entity-component-system architecture. To use it, you define component types, and put a bunch of components in a map to make an entity. The rule for entities is that they can only have one component of any given type, so I figured I would use the class to index it. However, since this doesn't seem possible, I think I'll just make my own "defcomponent" macro which acts almost like defrecord, but makes sure that the constructor associates an appropriate keyword type tag in the metadata. Looking up the metadata is slightly slower than normal type reflection, but I doubt it will make much of a difference. On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote: > > I don't think there's a general workaround, and I'm not sure I have > enough context to know what you are doing specifically. > > On Wed, May 18, 2016 at 2:28 PM, JvJ wrote: > >> I suspected as much. It would be possible to mitigate the problem by >> not using the repl, but I want the library I'm making to be built around >> a >> repl-oriented workflow (like every good clojure library should). >> >> Is there any way around this, or do I have to resort to :type >> metadata? >> >> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: >>> >>> When you reload a namespace with a record, the class for that record >>> gets recreated. It will be functionally equivalent, but a different >>> object. I'll bet that classes hash on identity. (Though if they >>> hashed on >>> name, you'd still have this problem.) >>> >>> On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: >>> I'm encountering a very strange error in some tests. The details are a bit complex, but I'm using type-indexed maps. So, given an object o, the map would be {(type o) o}. When I try to lookup with the key (type o), I don't get the value, even though I can clearly see it in the map. I have a map instance called new-still in my tests, and I can clearly see that this is its value {specs.core_test.Position {:x 0, :y 0}} However, when I try to compare the first key to the Position class (which it should be), I get this: Fail in run-systems-tst expected: (= (first (keys new-still)) Position) actual: (not (= specs.core_test.Position specs.core_test.Position)) How is it that the class specs.core_test.Position is not equal to itself?? Is this a bug, or just some quirk of compilation? Thanks. -- 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
Re: Is java.lang.Class not a dependable map key?
I think I will do something like this. Maybe instead of converting the class name to a keyword, I'll just make a separate protocol IComponent or something, that has a component-type function that returns a constant keyword determined by the macro at compile time... On Wednesday, 18 May 2016 15:50:21 UTC-7, tbc++ wrote: > > Well, if you store it in metadata you'll have to look it up in the > metadata which is a hashmap lookup. As a method on a class it's a method > call that returns a constant. > > On Wed, May 18, 2016 at 3:12 PM, JvJ > > wrote: > >> Will it be much better than type metadata, though? >> >> On Wednesday, 18 May 2016 12:50:48 UTC-7, tbc++ wrote: >>> >>> Or define components to have a member called (name-as-kw [this]) >>> returning a keyword version of the name of the type. >>> >>> On Wed, May 18, 2016 at 1:31 PM, James Reeves >>> wrote: >>> Why not use the name of the class as the key? - James On 18 May 2016 at 20:02, JvJ wrote: > I'm creating an entity-component-system architecture. To use it, you > define component types, and put a bunch of components in a map to make an > entity. > > The rule for entities is that they can only have one component of any > given type, so I figured I would use the class to index it. However, > since > this doesn't seem possible, > I think I'll just make my own "defcomponent" macro which acts almost > like defrecord, but makes sure that the constructor associates an > appropriate keyword type tag > in the metadata. > > Looking up the metadata is slightly slower than normal type > reflection, but I doubt it will make much of a difference. > > On Wednesday, 18 May 2016 11:43:22 UTC-7, Jason Felice wrote: >> >> I don't think there's a general workaround, and I'm not sure I have >> enough context to know what you are doing specifically. >> >> On Wed, May 18, 2016 at 2:28 PM, JvJ wrote: >> >>> I suspected as much. It would be possible to mitigate the problem >>> by not using the repl, but I want the library I'm making to be built >>> around >>> a repl-oriented workflow (like every good clojure library should). >>> >>> Is there any way around this, or do I have to resort to :type >>> metadata? >>> >>> On Wednesday, 18 May 2016 11:07:37 UTC-7, Jason Felice wrote: When you reload a namespace with a record, the class for that record gets recreated. It will be functionally equivalent, but a different object. I'll bet that classes hash on identity. (Though if they hashed on name, you'd still have this problem.) On Wed, May 18, 2016 at 1:31 PM, JvJ wrote: > I'm encountering a very strange error in some tests. > > The details are a bit complex, but I'm using type-indexed maps. > > So, given an object o, the map would be {(type o) o}. When I try > to lookup with the key (type o), I don't get the value, even though I > can > clearly see it in the map. > > > I have a map instance called new-still in my tests, and I can > clearly see that this is its value > > {specs.core_test.Position {:x 0, :y 0}} > > > However, when I try to compare the first key to the Position class > (which it should be), I get this: > > > Fail in run-systems-tst > expected: (= (first (keys new-still)) Position) > actual: (not (= specs.core_test.Position > specs.core_test.Position)) > > > > How is it that the class specs.core_test.Position is not equal to > itself?? > Is this a bug, or just some quirk of compilation? > > Thanks. > > -- > 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.
[ANN] New Clojure Podcast: defn
Hello Everyone, Just wanted to let you know that we started a new podcast about Clojure: https://defn.audio We published our first episode and plan to release a new one every two weeks. It is available on iTunes https://itunes.apple.com/podcast/defn/id1114899563 and SoundCloud: https://soundcloud.com/defn-771544745 You can also get the RSS feed via http://feeds.soundcloud.com/users/soundcloud:users:220484243/sounds.rss We'd appreciate if you can tune in and give us some feedback! Thanks for listening, Vijay & Ray -- 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.