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 <ja...@booleanknot.com 
> <javascript:>> wrote:
>
>> Why not use the name of the class as the key?
>>
>> - James
>>
>> On 18 May 2016 at 20:02, JvJ <kfjwh...@gmail.com <javascript:>> 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 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
>>> clojure+u...@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 clojure+u...@googlegroups.com <javascript:>.
>>> 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 
>> <javascript:>
>> 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 <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 clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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