3 ms·

> Just use semantic names like `HTTPStatus.NotFound` and you wouldn't have a problem in the first place. Have to disagree there: when I tried re-implementing a

> Just use semantic names like `HTTPStatus.NotFound` and you wouldn't have a problem in the first place. Have to disagree there: when I tried re-implementing a basic websocket server in multiple languages (https://news.ycombinator.com/item?id=43800784 https://news.ycombinator.com/item?id=43800784), I found it so frustrating when they'd insist on hiding the raw close-codes behind pretty names, because it meant having to stop what I was doing to jump into the documentation to figure out what pretty name they gave a particular close code. All I wanted was to return 1003 (https://datatracker.ietf.org/doc/html/rfc6455#section-7.4.1 https://datatracker.ietf.org/doc/html/rfc6455#section-7.4.1) if the websocket sent a string message, but: - Dart calls this "unsupportedData" (https://api.dart.dev/stable/latest/dart-io/WebSocketStatus/unsupportedData-constant.html https://api.dart.dev/stable/latest/dart-io/WebSocketStatus/u...) - Java-Websocket calls this "REFUSE" (https://javadoc.io/doc/org.java-websocket/Java-WebSocket/latest/org/java_websocket/framing/CloseFrame.html#REFUSE https://javadoc.io/doc/org.java-websocket/Java-WebSocket/lat...) - Ktor calls this "CANNOT_ACCEPT" (https://api.ktor.io/ktor-shared/ktor-websockets/io.ktor.websocket/-close-reason/-codes/-c-a-n-n-o-t_-a-c-c-e-p-t/index.html https://api.ktor.io/ktor-shared/ktor-websockets/io.ktor.webs...) And some others: - .NET calls this "InvalidMessageType" (https://learn.microsoft.com/en-us/dotnet/api/system.net.websockets.websocketclosestatus?view=net-10.0 https://learn.microsoft.com/en-us/dotnet/api/system.net.webs...) - libwebsockets calls this "LWS_CLOSE_STATUS_UNACCEPTABLE_OPCODE" (https://libwebsockets.org/lws-api-doc-main/html/group__wsclose.html https://libwebsockets.org/lws-api-doc-main/html/group__wsclo...) Just... why? Just call the thing 1003 and link to the spec.

sedatk 1y ago
If you don’t want to deal with that, you can just use the number. Some APIs have integer overloads for that purpose, but you can also typecast. I don’t find HTTPStatus.`1003` more helpful than 1003.
- Defletter 1y ago
  Many of the languages/platforms/libraries that I used (eg: Bun) do not provide any kind of named-constant for this reason: just type 1003. But the value of named constants is that you can attach documentation to them. To clarify something I said earlier, I would rather have to stop what I'm doing to look at documentation (something that can be done within the IDE) than have to open up a browser and read through the specification to figure out what some magic-value means. Having a provided named-constant that tells me what 1003 means is very useful for me and for other maintainers or contributors to the project, and it can link to the spec for more information anyway. Just having raw magic-values is not great for maintenance. Likewise, having pretty names entirely detached from the actual close-code makes searching for places where that close-code is used much harder. Even just "1003_REFUSE" or "1003_CANNOT_ACCEPT" is so much better.

sedatk 1y ago

If you don’t want to deal with that, you can just use the number. Some APIs have integer overloads for that purpose, but you can also typecast. I don’t find HTTPStatus.`1003` more helpful than 1003.

Defletter 1y ago
Many of the languages/platforms/libraries that I used (eg: Bun) do not provide any kind of named-constant for this reason: just type 1003. But the value of named constants is that you can attach documentation to them. To clarify something I said earlier, I would rather have to stop what I'm doing to look at documentation (something that can be done within the IDE) than have to open up a browser and read through the specification to figure out what some magic-value means. Having a provided named-constant that tells me what 1003 means is very useful for me and for other maintainers or contributors to the project, and it can link to the spec for more information anyway. Just having raw magic-values is not great for maintenance. Likewise, having pretty names entirely detached from the actual close-code makes searching for places where that close-code is used much harder. Even just "1003_REFUSE" or "1003_CANNOT_ACCEPT" is so much better.