Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Ruby has support for the for i in a syntax, but no one really uses it. One of the design principles of Ruby is it's readability, and I find
for i in a
...
end
much more readable (and easier to type) than
a.each do |i|
...
end
Why is it not preferred? Do others not also find it more readable? Is it for consistency reasons, e.g., relation with other functions like each_with_index and variable scoping?
For me, it's uniform syntax. When I am going to do something with array a, I just start typing a.. What am I going to do? Filter? a.select; determine the size? a.size. Iterate? a.each etc.
Iterating an array is nothing special and requires no special language construct. Also eachwithout an immediate block results in an Enumerator, which can be chained with other methods.
Then again, Ruby does have a fine for i in a loop. So if you are more comfortable with a for loop: by all means, use a for loop.
Because for loop is less objective and more limited in use.
From the OOP point of view, possibility of iterating through elements of an object is a property/characteristic of that object. Using explicit "outer" way either with a global function or a keywords find redundant, inconsistent and less objective (encapsulation).
for is also more limited, it allows only iterate through object elements. Enumerator#each on the other hand allows you much more. You may play with enumerator object like chaining with other methods before values unpacking, passing named blocks, methods converted to procs etc.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
7.2 Blocks in Ruby says..
"block is a piece of code that can't be stored in a variable and isn't an object. It is, as a consequence, significantly faster than a lambda, but not as versatile and also one of the rare instances where Ruby's 'everything is an object' rule is broken"
Going by Best explanation of Ruby blocks?, that doesn't seem right.
Are blocks (Proc) objects? And thus don't break the everything is object rule in Ruby?
No, blocks are not (Proc) objects (although it is easy to map from one to the other).
Obviously, "everything is object in Ruby" is wrong in the absolute sense. A character is not an object. Even if limit your attention to tokens, keywords are not objects; comments are not objects; parentheses are not objects. So it is not surprising that a block is not an object.
Every proposition has contexts in which it is to be interpreted. When people say "everything is object in Ruby", the context is "with respect to what some major languages regard as atomic/scalar, such as numerals, etc."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In Ruby, is there a preference for which level of parentheses to elide, or does it depend on the situation (in which case, what guidelines should be followed)? Sources are appreciated.
For example, is either
do_something do_something_else(...)
or
do_something(do_something_else ...)
better than the other?
You want a rule to decide when to omit parentheses and when not. And that should be based on the method. (It is cumbersome to base the rule depending on the context, i.e., always omit the innermost parentheses, or always omit the outermost parentheses., etc.)
And there are methods that are usually only used at the outermost level (i.e., do not become an argument of another method call), as opposed to no/few methods that only appear as the innermost level. Typical examples of the former are DSL methods (methods that are conventionally used without parentheses like puts, p can be considered parts of the DSL provided by Ruby itself).
Once you decide to base the rule on what the method is, it follows naturally that you would be omitting the outermost parentheses that appear with particular methods.
This is a primarily opinion-based question, but Ruby Style Guide is a good (best?) reference when style-related questions appear.
Assuming it should be consistent with rest of the assert in tests, and looking at way asserts are used in Rails tests (i.e. with no parenthesis), it will be apt to use
assert method(param1, param2, etc)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Arrays in PHP work both with numeric keys and string keys. Which is awesome.
Ex:
$array[0] = "My value.";
or
$array['key'] = "My value";
Why doesn't go implement arrays like this?
What's the benefit for having two different concepts and syntax (maps) in Go?
I believe I'm failing to see the usefulness behind this.
Go is not PHP. While a few higher-level languages share this abstraction, it's not very common. Arrays and Maps are different data structures for different purposes.
PHP's arrays are actually hash tables underneath. Go has true arrays, and it has slices which are a more powerful abstraction over arrays.
Having real arrays, gives you predictable memory layouts, and true O(1) indexing (the same goes for Go's slices, which use an array internally). Using a hash-map for the underlying data store costs you a constant overhead for all operations, as well as not being able to better control data locality.
One of the primary reason is that arrays have order, and maps do not, which has important implications as stated here:
When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next. If you require a stable iteration order you must maintain a separate data structure that specifies that order.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I know that there are a couple ways to loop in various languages - a "for" loop, a "while" loop, a "do-while" loop, and just "loop" in Ruby for example. And I know there are various functions in every language that are pre-written in that language - for example the .each function in Ruby (which I think is based on a "for" loop and written entirely in Ruby and is replicable just using the language).
But what is the logic behind loops? Are they programmed from control flow statements in Assembly or even binary? And in fact, now that i think about it, what is the origin of all programming structures in general (such as variable name/value associations, arrays, hashes, etc - sorry if my terminology is wrong). Can anyone recommend sources to read more on this?
Loops in general are jumps in the program flow. When you compile your code i.e. in C, it gets "converted" to assembly, where you can see that loop structure:
So you start at a certain adress and do some stuff (i.e. ADD) which basically is everything inside your loop. At the very end then is a jump instruction back to the adress where you started. Breaking is is then i.e. made through a conditional jump inside your loop and thus you don't get to the jump instruction again and therefore do not loop again.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Can anyone list out the immutable objects in Ruby..
I saw Ruby - Immutable Objects this and I know about how to convert mutable objects into immutable objects but no clarity on immutable objects in ruby.
It's been my experience that you have two choices:
Aggressively freeze any objects, and this means deep freeze where you not only freeze the main object but any contained objects, in order to prevent modification.
Be disciplined about not modifying the objects in certain sections of your code.
The second approach is what most applications use because once frozen there's no way to un-freeze something. Objective-C has mutable and non-mutable variants of many objects, C++ has const that can prevent modification of any object, but there's no such thing in Ruby.
This is largely because Ruby methods are free to do whatever they want with very little in the way of constraints. Can a reader method modify the state of the object? Yes. You might have a very good reason for doing this and Ruby won't get in your way.
If you're writing code that depends on objects being in a non-changing state, make a copy, freeze it, and use that for reference. This will probably slow down and complicate your application considerably, so it's a very heavy handed approach.
The best method is to share as little information as is necessary, provide interfaces to this information that are read-only by design, and avoid tampering with things outside of specific circumstances by employing proper locking measures.