jackfirth / rebellion

A collection of core libraries for Racket
https://pkgs.racket-lang.org/package/rebellion
Apache License 2.0
80 stars 16 forks source link

`make-named-object-custom-write` requires that `object-name` return a symbol #526

Open dented42 opened 6 months ago

dented42 commented 6 months ago

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 for make-named-object-custom-write be changed to something along the lines of

(->* (symbol?) (#:name-getter (-> any/c (or/c symbol? string? bytes? number? #false))) custom-write-function/c)

Or even

(->* (symbol?) (#:name-getter (-> any/c (or/c object-name/c #false))) custom-write-function/c)

and have the module provide object-name/c.

jackfirth commented 5 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.

dented42 commented 5 months ago

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

jackfirth commented 5 months ago

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.

dented42 commented 5 months ago

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.