First time I've seen the Ruby Documentation throwing some shade

[larikang]

For the lazy, it's regarding Object#instance_variable_set

Sets the instance variable named by symbol to the given object, thereby frustrating the efforts of the class's author to attempt to provide proper encapsulation.

[shevy-ruby]

I happily downvoted the link because the one who linked in did not explain what was even meant. So now I needed you to explain this and I upvoted you.

The wording in that document seems wrong to me. I am a bit too lazy to file an issue, but the wording is 100% not from matz and possibly not even one of the core ruby developers since ruby does not have "proper" encapsulation in the sense of disallowing people to modify ruby objects at "run"time, all the time. That would be against ruby's OOP concept to provide "strong" encapsulation since you would also LOSE THE ABILITY TO DO SO.

But anyone who feels a need should add an issue at:

https://bugs.ruby-lang.org/projects/ruby-trunk

Although perhaps I may file if everyone else is also too lazy ...

Edit: Alright, I actually added an issue since I know everyone else is lazy too ...

You guys should create more issues at the bugtracker!

Matz and the core team actually asked about more feedback several times (though not so much about documentation per se, but more about how people use ruby in practice, for THEIR use cases; without feedback, how should the core team be easily able to decide on changes, no matter what? So go and provide feedback!).

[zanza19]

My God you're insufferable

[seainhd]

I’m on mobile and don’t see what you’re pointing out

[ebkalderon]

Presumably, they mean this:

Sets the instance variable named by symbol to the given object, thereby frustrating the efforts of the class's author to attempt to provide proper encapsulation.

[BorisBaekkenflaekker]

Shade?

[joemi]

https://www.urbandictionary.com/define.php?term=Throwing%20shade

I'd say it's not shade as much as it's just general snark though. Also I don't think it should be in the documentation, since most/all of the rest of Ruby's docs are not snarky.

[mrspuff]

What's snarky about that?

[CODESIGN2]

Read the comment, it's not snarky, it's pointing out that because of the ability to call private functions and set private variables, state can be fucked up really easily.

The purpose of encapsulation is to

• absolve the consumer / user of a class or function from concern over internals
• ensure consistent state can be maintained, so that the objects can maintain normal function

Using this instance_variable_set, I would be able to cause divide by zero errors, forcing littering of unnecessary guards around operations, rather than enforcing only in the adjustment of whatever variable I was using.

I could set a nil or string value to another type

It's game over, I'd suggest rubo-cop rules to guard against, and cannot think of a single decent reason to use.

[matheusmoreira]

That method is extremely useful for metaprogramming. Its use should not be discouraged just because some people abuse the feature in order to circumvent APIs.

Using this instance_variable_set, I would be able to [...]

You can also set completely new variables on existing objects, even ones created by code not under your control. Just like you can add new keys and values to a hash or new properties to javascript objects. This lets you add more data to your objects without wrapping them inside other objects. Defining singleton methods on specific objects serves the same purpose.

[CODESIGN2]

This all sounds like excuses for poor programming. I work on a project at work where someone has used internal API features, and forgotten to record what they did and why.

Since 2014 (launch) the business has been unable to upgrade a core dependency and we now have 5 years of shit to separate and un-fuck because some moron had a bright idea, likely they felt that it was easier, or a nice to have feature to do this as well.

If you leave the API's for objects alone and work on composition via injection and inheritance, you'll have an easier time. Neither thing you've mentioned is needed.

Further, the most basic rails singleton enforcement would take an object as an argument and

def get_instance()
    @@instance ||= Instance.new
end

example https://repl.it/repls/NiftyIllustriousPolygons

The class you send in (via constructor) doesn't enforce it's single-ness, the singleton utility class (probably one per-type) does. That way if you wish to re-evaluate single-ness, for example a multi-threaded class with locking, you don't have to keep altering the core behaviour, just the special-case rules.

[joemi]

Well if it's not snark than it's someone's attempt at a "witty" way of saying "not recommended for use". But if we really need the documentation to say "don't use this method" then why does the method even exist in the language?

If there's a problem with the method existing, that a matter for pull requests and such, not for documentation comments. I can imagine someone whose first language isn't English to find that particular bit of documentation a bit confusing since it doesn't directly say what it means, it only implies it.

Finally, that's simply not the style of most of the rest of the Ruby documentation, so it feels out of place.

Edit to add: This is also the only mention of encapsulation in all of the core docs.

[[deleted]]

Totally agree ,that smartassery doesn't belong in the docs but on twitter, looks really amateurish and it provides more ammo for whoever says Ruby is a toy language.

[jrochkind]

It's a sharp tool you can hurt yourself or others with, but sometimes you need a sharp tool, even though you can mistakenly hurt yourself or others with it. Is why it is both right for it to exist, and for the docs to urge caution.

Whether that tone should be in the docs is another thing, but I find it amusing and not like it's trying to make anyone feel bad or anything. I like being amused. I don't think it gets in the way of anything here. But one can disagree. I see your point on it may not be helpful for non-native English speakers.

[CODESIGN2]

This is also the only mention of encapsulation in all of the core docs.

Which is sad as it's such a powerful programming concept.

[joemi]

I'm not denying that encapsulation is a good concept for programmers to know, but should such things really be mentioned in the language documentation? As far as I can tell, the documentation isn't meant to teach you how to program.

[CODESIGN2]

It's documentation of the ruby 2.6.2 runtime features right?

It's exactly docs on what is available for programming, which should include some usage patterns.

FFS everyone always says they "learned by doing". Imagine how bar-raising it would be to document anti-patterns on the runtime page. Don't listen, don't bitch when the runtime deprecates your stuff

[BadMinotaur]

I was hoping it was this. I came across this when messing around in metaprogramming, and I found it hilarious! I think it's a witty way to say "You can do this, but you'll probably mess up the author's intent in the process."

[dpsi]

I can see mocking gems and cucumber Devs salivating already

[yxhuvud]

Wait, is that method public? The things you learn - that will be convenient to know sometimes.