Hacker News Reader

Comment by jb1991 | Hacker News Reader

jb1991

While true, if your language doesn’t support such a type, then the burden for such a name goes to the parameter, does it not?

View on HN

> While true, if your language doesn’t support such a type

You'd be surprised where the support is. In C#, you would declare a struct type with one read only field of type double, and range validation (x <= x <= 1) in the constructor.

this is the "value object" pattern. http://wiki.c2.com/?ValueObject

Yes there's a bit of boilerplate - especially since you might want to override equality, cast operators etc. But there is support. And with a struct, not much overhead to it.

I don't think runtime validation is that special. You can bend most languages into this pattern one way or another. The real deal is having an actual compile-time-checked type that resembles a primitive.

Actually what I want is just the reading experience of seeing

"public Customer GetById(CustomerId id)" instead of "public Customer GetById(string id)" when only some strings (e.g. 64 chars A-Z and 1-9) are valid customer ids.

Compile-time validation would be ideal, but validation at the edges, well before that method, is good enough.

See: "Primitive Obsession" https://wiki.c2.com/?PrimitiveObsession

Usually cured by using Value objects. I wish this done more in OO code.

Could it be better supported in these languages? Yes, for sure. But is it true that "these language do not support such a type" at all? No.

Joel, on the original purpose of Hungarian notation:

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

Very insightful article. I wasn't aware of "Apps Hungarian", which indeed seems like a much better idea of the redundant "System Hungarian".

Usually that would go to the documentation of the parameter, plus a run-time assertion to check that received values are valid.

But the best documentation is the code itself that is documentation. I mean, well that’s kind of a cliché, but names can carry a lot of meaning.

Or you could approach it another way, store the data using the full range of the system float type and normalize it to [0,1] through accessor methods.

Can float types even support 0, 1 inclusive? You just can't represent natural numbers like that with floats...

The main issue with techniques such as this, which are certainly easy to do, is that if it’s not in the type system and therefore not checked at compile time, you pay a run time cost for these abstractions.

You can't represent the interval from 0 to 1 inclusive without significant run time cost just because of the way floats work.

Reply on news.ycombinator.com