Docs call bang methods “dangerous": “the dangerous method implies that...[it] permanently modifies its receiver.” Seems to tightly couple “dangerous” with “mutation,” but could “danger” include other risks, as Piotr and Gregory suggest? Maybe, docs suggest a stronger correlation than was intended. - ThreadSky

hacopian.de • 29 days ago

Docs call bang methods “dangerous": “the dangerous method implies that...[it] permanently modifies its receiver.” Seems to tightly couple “dangerous” with “mutation,” but could “danger” include other risks, as Piotr and Gregory suggest? Maybe, docs suggest a stronger correlation than was intended.

Comments

hacopian.de•29 days ago

Here's a good example: `exit!` exits the process without calling exit handlers like its counterpart `exit` does, a potentially dangerous action that does not involve mutation. https://docs.ruby-lang.org/en/3.4/Kernel.html#method-i-exit-21

skillstopractice.com•29 days ago

That is what I was saying...

The convention as best as I know it is that a bang method is the more dangerous version of a method with the same name without the bang.

This is true for exit/exit!

But Piotr mentioned that there were methods in core without a corresponding non-bang version...

chastell.net•29 days ago

Yeah I totally fucked that up, apologies, you’re right that all bang methods should have a non-bang, somewhat safer versions.

That said… 😇

skillstopractice.com•29 days ago

This is what I imagined you might provide if asked, thanks. :)

Now I wonder what percentage of all the bang methods in Ruby that represents...

(I actually think looking at core Ruby to figure out what's canon is not the way, but as an empirical observation it's interesting!)

skillstopractice.com•29 days ago

Also I had no idea what RBS was and now I'm quite curious about taking a closer look at it!

https://github.com/ruby/rbs?tab=readme-ov-file#rbs

chastell.net•28 days ago

IMHO this is the way to do typing in dynlangs – separate signature files, tooling can show this along the code when needed (vs ‘let’s annotate everything everywhere’).

skillstopractice.com•29 days ago

... that to me doesn't make sense, just like it doesn't make sense to put a ! on something that mutates the receiver unless a same named non-mutative version is also provided.

(In that case the mutation is why it's "more dangerous")

skillstopractice.com•29 days ago

There are plenty of methods that don't use a ! in core to indicate modifying the receiver as well, clear/update/push/pop/etc.

It's only when you have things like sort / sort! that it matters as far as mutability goes.

hacopian.de•29 days ago

Yeah, the counterpart pattern is not strictly adhered to. See https://docs.ruby-lang.org/en/3.4/IO/Buffer.html#method-i-and-21 and https://docs.ruby-lang.org/en/3.4/Socket.html#method-i-ipv6only-21. But as we've said even when we have a counterpart, mutation may not be the concern, as with exit/exit!. I'm not really sure what to think; gardens evolve, I guess.

skillstopractice.com•29 days ago

I'm assuming & is the non-mutative version of and! there.

For ipv6_only! that seems like a weird edge case moreso than an intentional design but not sure about that one!

Comments

Posting Rules

Reply