Awesome, this was a great read.

Hi @ufuk.dev, The article is live here: dev.to/hinokami_dev...

Thank you @byroot.bsky.social for the detailed feedback. Your insights on interning and hashing made it much stronger.

Given `foo.bar.` do autocomplete...

I see the code as calling `make_shareable` right after initializing itself with `value`, so I think it does make the value shareable at that point. But, agreed, swapping it out with a different value would mutate the state.

Doesn't `make_sharable` deep freeze the object? If so, making `self` sharable should make the `value` sharable as well, right?

You'll have to write one yourself, I am afraid.

I still call it Namespace, and I don't think there have been any code changes to make it Box yet, either.

My understanding is that 4.0 moniker is more to celebrate the 30 year anniversary than any breaking change. Ractors being stable (yet possibly still marked as experimental since the API may still change), ZJIT and the introduction of Namespace might end up being the headline features of 4.0.

YARD is ok, but its type syntax is not expressive enough for real world code. IMO that makes it fail at type annotations.

But RBS inline *is* with comments on top of your code, so you don't need another file and it is not intrusive to your Ruby code either. Think YARD annotations where people would try to put types of arguments but with a way more expressive type syntax.

Ok, thanks, that explains a lot. It seems RBS inline has special syntax for embedding RBS syntax in comments: github.com/soutaro/rbs-...

You should be able to use that. @soutaro.bsky.social can help more, though.

Right, if you are using RBS annotations with Sorbet, those won't work, because Sorbet only does nominal types and has no way to support structural types, like implicit interfaces, thus conversion isn't possible. You will have to either use your own annotation or fall back to Object, any or top.

How so? It has the concept of implicit interfaces which declare duck types, no? github.com/ruby/rbs/blo...

I understand your point and in general I am in your camp. For naming types though, I am still inclined to think of `bool` and the union of `true` and `false` as literal values, whereas the general union of "true" and "false" as `boolish`.

Yes, you could do that, but that still implies that the return type responds to all the methods on Object (including Kernel), as if it is intentional. However, the intention is to return a value that can be checked for truthiness, but not for using the value for other reasons.

But I think my point stands. With `boolish` you are trying to represent a type that can be a true or a false *value* without implying that it will respond to specific methods.