I seem to be on the other side of the fence on this one from everyone else. I think your first way seems a little cleaner, at the very least it's the way I tend to do things: inside my "init" I might call a "generate_something" method that returns "something" which I then use to set the "something" attribute.

What everyone else is telling you is essentially that the wall of the object class is the only encapsulation barrier that you need to respect, and when you're on the inside of it anything goes (or almost anything). What I would suggest is that the situation is a little fuzzier than that, and it's not a bad idea to try to organize the way communication happens inside of the object, as well as between objects.

Possibly a related issue: I often find that when I want to make sure that one thing is kept up to date if a change happens to something else, it's very tempting to bury a call inside the "something_else" accessor to some other routine that will refresh what ever needs to be kept up to date. That's a very robust (if not always efficient) way of doing things -- the trouble is when I come back six months later, I tend to forget about it, and assume that all my accessors are simple and stupid accessors. So: nice trick, but it's good to take it easy on it...