Replace every Symbol | string & equiv. with the new interned

[ParadoxV5]

So, with #1469, we have finally decided on what to call Symbol | string 👌.

This PR is a follow-up to #1488 to assimilate ALL Symbol | strings and equivalents to use interned. Regexp: /symbol \| string|string \| symbol/

• (At this scale, are we sure RBS neophytes can understand what interned is?)
• A majority of the population actually uses String with an uppercase S, i.e. no _ToStrs accepted. But given that nearly if not all of them are C-implemented, I doubt they actually reject _ToStrs and bet that they’re RBS oversights.
• Also purged are Object::name and (introduced with Allow Symbol | string to Module methods #1321) Module::id [EDIT: and Net::HTTPHeader::key]. They might be used in the wild, howëver, so backward-compatibility requires undeleting those type defs.
• There’s also a lot of now-Integer | interneds – how about int_interned?

c.c. @sampersand and @soutaro, author and reviewer of #1469 respectively
#good-first-issue

[ParadoxV5]

Unknown alias name: interned? That is not #good-first-issue, need help

[ParadoxV5]

Another three: there’re many TrueClass rather than true, FalseClass rather than false and TrueClass | FalseClass/true | false rather than bool. Changing things to bool could screw up with the tests, though, so I’m passing.
Mean while, perhaps the RBS community too would benefit from a style guide; since moreover, there’s some inconsistency with the use of ::MyModule vs. MyModule.

[sampersand]

I tried doing this when interned was first added, but there's a lot of places to check—Are things annotated with String | Symbol actually interned and someone just forgot the _ToStr case, or does it actually not accept _ToStrs. I planned on just migrating them as I went.

[sampersand]

I tried doing this when interned was first added, but there's a lot of places to check—Are things annotated with String | Symbol actually interned and someone just forgot the _ToStr case, or does it actually not accept _ToStrs. I planned on just migrating them as I went.

[soutaro]

@ParadoxV5 Thanks for this PR.

• I'm good to replace existing union types to interned.
• I'm good too to replace existing id, name, ... to interned while not 100% sure if it can be unified safely, but looks like good.
• Please keep the existing id and name definitions to avoid breaking existing type definitions (I know it's impossible but deleting the definitions is a clear incompatibility.)

[soutaro]

Unknown alias name: interned? That is not #good-first-issue, need help

#1502 will fix the issue.

[ksss]

Please excuse any disruptive comments.
Is interned a decided name?

Certainly String#intern and Symbol#intern are methods that return Symbols.

But in CRuby's API, interned seems to mean frozen string.

https://github.com/ruby/ruby/blob/89a4fd67453b33b7c709c715f01cfeff8efb2f9d/string.c#L11870

Does the intention come across with "interned"?

[ParadoxV5]

Found this annotation in

rbs/schema/annotation.json

Line 3 in fce99b9

"title": "Annotation associated to a declaration or a member: `%a{rbs:test}`, `%a{steep:deprecated}`, ...",

but otherwise no deprecation annotation documented in either RBS or Steep. Not sure if it’s appropriate.

[soutaro]

@ksss

Is interned a decided name?

We are free to rename it until the RBS 3.3 release. 😃

But in CRuby's API, interned seems to mean frozen string.

My understanding is that intern is an one-to-one operation, which maps a string to an ID. It's not a frozen string. (Frozen string is also interned to reuse it though.)

The type here is for something that will be interned. So I don't think it's a bad name. (Maybe internable would make more sense?)

We may be able to say it's too much connected to the implementation detail. Calling it in more abstract way, like name, may make sense.

[sampersand]

I'm not a huge fan of either name or id for a few reasons.

Just like how Kernel#id was removed in favor of Kernel#object_id so that custom.id functions wouldn't conflict, I'm worried that using name or id in core RBS could lead to people with issues: They seem like fairly common type aliases that people might use. (Moreso id than name, but I could forsee both of them). I picked interned (although it really shoulda been be intern...) because I doubt anyone would actually used it.

Additionally, name doesn't feel entirely right to me: It feels like it should be only used in cases where it's a "key" (such as Class.define_method or Thread#[]), but in other places where Symbol | stringare accepted it feels a bit awkward, such asProcess#kill (def self.kill: (Integer | name signal, *int pids) -> Integer) or Regexp.escape (def self.escape: (name str) -> String`).

I agree that interned/intern is a bit awkward, and I'd be open to other suggestions. Maybe stringy or stringish? IDK, I don't think there's a good answer.

[ksss]

Thank you for your response. I now understand the reason for using interned.
I won't interject further.

It seems there might be a side effect to the issue related to the public nature of type aliases. Perhaps having private type aliases would be a good idea.

[ParadoxV5]

Perhaps having private type aliases would be a good idea.

Namespace it, such as Net::HTTPHeader::key. And for truly private-feeling ones, why make then in the first place.

[soutaro]

👍

Will merge this PR, after reviewing other open PRs to minimize conflicts.

[ParadoxV5]

@soutaro I resolved the merge conflict