4 ms·

Free-form identifiers are neat for test-case naming, but not for `HTTPStatus.`404``. I think having `HTTPStatus.Error404` was a bad idea to begin with. Just use

by sedatk 1y ago

Free-form identifiers are neat for test-case naming, but not for `HTTPStatus.`404``. I think having `HTTPStatus.Error404` was a bad idea to begin with. Just use semantic names like `HTTPStatus.NotFound` and you wouldn't have a problem in the first place. Now, a single character typo can easily make a 404, 403 and create a bug. It's less of a problem with semantic names. If you want constrained numeric types in Swift, that's another problem to tackle. But `HTTPStatus.`404`` seems to be the least ideal way to go about it. It lets you do stuff like to declare `HttpStatus.`404`` with a value of 403 too.

jshier 1y ago
Yeah, the feature is mostly about test cases and macro generated code. The numeric property names are far less useful, as the good syntax requires tick marks: .`404`
hombre_fatal 1y ago
You might mess up 403 vs 401 in this system, but then in the next system you're messing up Unauthorized vs Forbidden. It's like when you see a poisonous snake and can't remember if "red touches yellow" is paired with "deadly fellow" or "friendly fellow".
- sedatk 1y ago
  Messing up Unauthorized vs Forbidden is a semantic problem, but 403 vs 401 can be either semantic or syntactical. It’s not like you’d mispress a key and get Forbidden instead of Unauthorized.
monkeyelite 1y ago
> case _401 or case error401. I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.
- sedatk 1y ago
  I don’t think it’s the sole reason, but I find that example odd for sure.
- iamcalledrob 1y ago
  I think this is kind of indicative of the Swift approach: if in doubt, add language features that make code look nicer. Not a fan personally, but Swift is littered with little "niceties" (complexities) like this.
DidYaWipe 1y ago
Yeah, this feature seems wholly unnecessary and possibly dumb. The example given is ridiculous. If you can't figure out what stripHTMLTagsFromString() does, you have way bigger problems than a lack of spaces.
Defletter 1y ago
> 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.

by sedatk 1y ago

jshier 1y ago

Yeah, the feature is mostly about test cases and macro generated code. The numeric property names are far less useful, as the good syntax requires tick marks: .`404`

hombre_fatal 1y ago

You might mess up 403 vs 401 in this system, but then in the next system you're messing up Unauthorized vs Forbidden. It's like when you see a poisonous snake and can't remember if "red touches yellow" is paired with "deadly fellow" or "friendly fellow".

sedatk 1y ago
Messing up Unauthorized vs Forbidden is a semantic problem, but 403 vs 401 can be either semantic or syntactical. It’s not like you’d mispress a key and get Forbidden instead of Unauthorized.

monkeyelite 1y ago

> case _401 or case error401. I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.

sedatk 1y ago
I don’t think it’s the sole reason, but I find that example odd for sure.
iamcalledrob 1y ago
I think this is kind of indicative of the Swift approach: if in doubt, add language features that make code look nicer. Not a fan personally, but Swift is littered with little "niceties" (complexities) like this.

DidYaWipe 1y ago

Yeah, this feature seems wholly unnecessary and possibly dumb. The example given is ridiculous. If you can't figure out what stripHTMLTagsFromString() does, you have way bigger problems than a lack of spaces.

Defletter 1y ago

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