Open dented42 opened 6 months ago
I'm of the opinion that letting names be non-symbols is confusing and weird. Smuggling data through the name doesn't seem like a good use of names. I think an object's name should correspond to an identifier somewhere in source code.
I agree, having them not be symbols is definitely confusing. However it does seem like non-symbol object names are a thing that exist in the wild, and the racket reference guide explicitly states that object-name
s can symbols, strings, and paths, or indeed any type. And in my case my struct is a custom representation for nonnegative integers, which is why my initial instinct was to make the name just be the actual number it represents.
My gut instinct was that make-named-object-custom-write
’s name getter should more closely match the actual signature for object-name
by at least accepting more of the ‘primitive’ types in racket, but I understand that would be implicitly encouraging the use of weird and confusing names. That being said I still think it would be useful for make-named-object-custom-write
to at least accept symbols and strings, given that those seem to be the most widely used and seem the best fit for the concept of a name.
Accepting symbols and strings might be reasonable, but honestly I think for the use case of a custom representation of numbers it's not a good idea to give them names in the first place. Those values don't need object identity, right? Structural equality and a custom printed representation that reflects it seems more natural to me.
Yes, admittedly numbers as names is a little weird, especially given that the built in numbers don’t have them. I’ve decided against that, in the end. I still think paths would be nice, since they are stringish, but allowing strings as well as symbols would be enough. Especially because make-named-object-custom-write
already has to convert symbols into strings in order to write them.
Bytestrings would probably be a mistake, given the encoding issue.
The documentation for
object-name
suggests that it can theoretically be any value, and specifically cites examples of symbols, strings, and byte strings. I also have a case where it makes sense for the name to be a number. I would suggest that the contract formake-named-object-custom-write
be changed to something along the lines ofOr even
and have the module provide
object-name/c
.