4 ms·
The whole premise here IMO is quite flawed. In real Ruby code I almost never use a for-loop. I can't think of a single use base for it. You always use .each or
by ajmurmann 3y ago
The whole premise here IMO is quite flawed. In real Ruby code I almost never use a for-loop. I can't think of a single use base for it. You always use .each or one of the other methods like .map or .select. while loops might get used, but I'm not sure I've ever seen a for loop in Ruby on any of the projects I've worked on with the exception of PRs from people who are brand new to Ruby
Edit: much more interesting would be the contrast to list comprehensions in Python and the somewhat associated crippled lambdas.
Another interesting one is Ruby's private methods being not accessible by other instances of the same class whereas Python's are (to be bizarrely) accessible by instances of the same class (like I can use your heart because we are both human?). I always justified this difference in my mind with Ruby object despite being of the same class potentially having different methods due to metaprogramming at runtime. But it's probably just due to the languages' respective ancestors.
- deleted 3y ago[deleted]
- zbentley 3y ago> Ruby's private methods being not accessible by other instances of the same class whereas Python's are (to be bizarrely) accessible by instances of the same class Not sure what you mean here; Python doesn't really have private methods.
- thangngoc89 3y agoIsn’t the double underscores __name would makes the method private?
- zbentley 3y agoNo, that trick merely renames ("mangles") the method name: https://docs.python.org/3/reference/expressions.html#atom-identifiers https://docs.python.org/3/reference/expressions.html#atom-id... This is very rarely used to try to achieve privacy in practice, not least because it's extremely easy to get around.
- ajmurmann 3y agoSure it's only mangled. I'm Ruby you can also still call private methods via .send(:method_name). IMO the goal of declaring something private is to make clear what you consider part of your object's public API and it's safe for others to call. It's mainly to protect callers from shooting themselves in the foot. Private provides no security. Your consumer will know better the actual situation they are in and if it's worthwhile taking the risk that your API might break them in the future or to write additional tests since they are doing something you as the author advise against. Of course it can also help enforce good design within your project. IMO it should be easy to bypass private constraints when a user makes that educated choice
- lbhdc 3y agoThe names get mangled, but are still accessible. class Foo: __bar = 1 f = Foo() assert(f._Foo_bar == 1)
- celdon25 3y ago> Python's are (to be bizarrely) accessible by instances of the same class (like I can use your heart because we are both human?) Have you never used C#, C++, or Java?
- Turing_Machine 3y agoYes. Unfortunately.
- ajmurmann 3y agoI have used all of those, but the design decision still doesn't make sense to me. Two instances of the same type might have absolutely nothing to do with each other in my domain.
- celdon25 3y agodef equals(other)
- CFLAddLoader 3y agoThe article says almost exactly the same things you complain about it not having. In pretty much the same order.
- lamontcg 3y agoRuby has 'protected' which is not Java-like protected, but implements "another instance can see my internals" semantics. It is useful for methods which take another instance as an argument like binary operators (e.g. `def ===(other)`) where you might need access to both objects internals.