Why not use the name of the class as the key?

- James

On 18 May 2016 at 20:02, JvJ <kfjwhee...@gmail.com> 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 <kfjwh...@gmail.com> 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 <kfjwh...@gmail.com> 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 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.

Reply via email to