Hacker News Reader

Comment by sedatk | Hacker News Reader

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.

View on HN

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

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.

> case _401 or case error401.

I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.

I don’t think it’s the sole reason, but I find that example odd for sure.

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.

> 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), 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) if the websocket sent a string message, but:

- Dart calls this "unsupportedData" (https://api.dart.dev/stable/latest/dart-io/WebSocketStatus/u...)

- Java-Websocket calls this "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.webs...)

And some others:

- .NET calls this "InvalidMessageType" (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__wsclo...)

Just... why? Just call the thing 1003 and link to the spec.

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.

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.

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`

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.

Reply on news.ycombinator.com