Recent searches
Search options
Thoughts on `array.fetch(index,0)` vs. `array[index] || 0`?
@postmodern I prefer || because if 0 is an expensive operation then it'll not be evaluated if array[index] is true, and be consistent so the same for even just 0.
@godfat @postmodern IIRC, if the default parameter in fetch is a constant (like `0`) there is no extra allocation. For expensive default, we should use the block syntax (`fetch(:k) { default }`).
|| is ambiguous, because the key could return any falsely value, which would trigger the default.
Which sometimes can be exactly what you want. So for me, it’s a big It Depends.
@fnordfish @postmodern A block can generate a closure which I would try to avoid as well. Sure it depends. For the most parts in my experience a hash table won't mix with nil or false or undefined, so falsely values are falsely which is not an issue. I see one exception for example could be general purpose caching, which can cache false or nil. In those cases I generally wrap them in another object or hide under methods so that's a different scenario.
@fnordfish @postmodern Might be off topic but another thing I don't really understand why is tap. Using it requires a closure, which if we just use a variable it's free from that, not to mention using tap often still requires a variable so I see no advantage using that...
@godfat @postmodern Totally agree that the cost of blocks is a bit annoying.
I find it quite interesting how we tend to use the same tools (Ruby) differently. There's a function like `fetch` that is intended to be used in specific scenarios, but we might tend to not use it for that. And not (only) because of aesthetic reasons, but because it might not perform as well in common scenarios.
Having said that, wouldn't it be cool to have a inline block notation, that wouldn't require a closure?
@fnordfish @postmodern yeah totally. If the compiler is smart enough knowing that a block can be inlined, then we won't have to worry about it, nor do we need to use a different notation. I am not sure if we're there yet though. A good point that maybe in the future (or right now?) we need to care less about the "syntax", even though users might accidentally make the block not being able to be inlined. More gotcha, but all trade offs I guess.