5 ms·

It seems like the reason for the author recommending the use of blocks/lambdas is to put the null-checking code in the `data_source` library, rather than user c

It seems like the reason for the author recommending the use of blocks/lambdas is to put the null-checking code in the `data_source` library, rather than user code. That is, if `data_source.getPersonById` doesn't find a person for that id, the block/lambda doesn't get executed at all, and there only had to be a null-check/not-found-check in one place. In your first Python example, both `.setPhoneNumber` and `.update_person` would be executed, and both would have to be smart enough to not persist anything from a "null object" (assuming data_source.person(id) returned a valid `Person` object with null fields).

jlarocco 13y ago
No, data_source.person(id) will return a collection of 0 or more Person objects, and the for loop will iterate over them and call .setPhoneNumber and .update_person methods on each them. The null check is replaced by iteration over a possibly empty collection. The author's example code appears to be doing the same thing, but iterating using Ruby's block syntax: data_source.person(id) do |person| person.phone_number = phone_number data_source.update_person person end I'm assuming data_source.person(id) would return 0 or more Person objects.
- masklinn 13y ago
  > The author's example code appears to be doing the same thing, but iterating using Ruby's block syntax: It's not iterating.
  - jlarocco 13y ago
    Does it matter? The null check is gone, so it achieves the author's primary goal. Conceptually, they both say "update this field for every entry having this ID" and at a quick glance the code for each language looks almost the same.
    - masklinn 13y ago
      > Does it matter? To an extent yes. I'd fully expect the Ruby version to run more code after the block has been executed, the Python version much less so (even though it is possible) for instance.
- dragonwriter 13y ago
  > The author's example code appears to be doing the same thing, but iterating using Ruby's block syntax Ruby's block syntax is essentially a method of passing an anonymous function as an argument to a method call. It is used by the standard libraries iteration method (e.g., Enumerable#each), but its use here is not iteration (though the teller could be implemented with iteration under the covers.) data_source.person(...) appears to be a method that takes an id, attempts to retrieve the person with the ID, and, if such a person object exists, yields the person object to the block. From the code, it doesn't look like it is designed to be a collection (it could be implemented on top of a finder that returned a collection, or a finder that returned either a record or nil.)
- dragonwriter 13y ago
  To illustrate that this is not iteration, assuming the existence of a DataSource class with a private find_person(id) finder that returns either a person object or nil, the method being called here could be implemented thusly: class DataSource def person(id) p = find_person(id) p && yield p end end

jlarocco 13y ago

No, data_source.person(id) will return a collection of 0 or more Person objects, and the for loop will iterate over them and call .setPhoneNumber and .update_person methods on each them. The null check is replaced by iteration over a possibly empty collection. The author's example code appears to be doing the same thing, but iterating using Ruby's block syntax: data_source.person(id) do |person| person.phone_number = phone_number data_source.update_person person end I'm assuming data_source.person(id) would return 0 or more Person objects.

masklinn 13y ago
> The author's example code appears to be doing the same thing, but iterating using Ruby's block syntax: It's not iterating.
- jlarocco 13y ago
  Does it matter? The null check is gone, so it achieves the author's primary goal. Conceptually, they both say "update this field for every entry having this ID" and at a quick glance the code for each language looks almost the same.
  - masklinn 13y ago
    > Does it matter? To an extent yes. I'd fully expect the Ruby version to run more code after the block has been executed, the Python version much less so (even though it is possible) for instance.
dragonwriter 13y ago
> The author's example code appears to be doing the same thing, but iterating using Ruby's block syntax Ruby's block syntax is essentially a method of passing an anonymous function as an argument to a method call. It is used by the standard libraries iteration method (e.g., Enumerable#each), but its use here is not iteration (though the teller could be implemented with iteration under the covers.) data_source.person(...) appears to be a method that takes an id, attempts to retrieve the person with the ID, and, if such a person object exists, yields the person object to the block. From the code, it doesn't look like it is designed to be a collection (it could be implemented on top of a finder that returned a collection, or a finder that returned either a record or nil.)
dragonwriter 13y ago
To illustrate that this is not iteration, assuming the existence of a DataSource class with a private find_person(id) finder that returns either a person object or nil, the method being called here could be implemented thusly: class DataSource def person(id) p = find_person(id) p && yield p end end