Critiques and their comebacks

Why all these small functions?

Critique

All these small functions make me have to jump around code instead of just reading linearly. It seems sometimes that it's unnecessary. For example, the not_a_mac_junk_path function: If I want to filter out those "mac junk" keys I just use lambda x: x.endswith('.DS_Store') in my filter, and Bob's your uncle!

Comeback

By the way, since you mention uncle Bob, know that uncle Bob (Robert Cecil Martin) very clearly favors small function. See this section of one of his lectures, for example.

Dogma and generalities aside, here's what I see for that particular example of not_a_mac_junk_path

• A lambda is not pickalable
• A function has a name, a doc, and a doctest, so it's easier for the user to know the why and what of that piece of code
• Every time you write that lambda, you could make a mistake.
• Bonus: If new edge-cases of the problem are discovered, there's a place to extend the solution for all to benefit.

There's a cons though, and they're related to that bonus "good reason":

• If someone changes the function badly, all users break (following this fear though, would bring us to only use copy/paste as a means of reuse)
• It'll be slower -- See here that I also filter out any paths that have __MACOSX anywhere. This only happens if your data was zipped on a mac, yet we do the check systematically. I say, though, that most of the time, other io processes will wash out that check overhead, and most performance costs are worth the extra correctness insurance.

Should storing data transform the data?

Critique

Those value transformer (data_of_obj and obj_of_data) bother me. I don't think data should be transformed when stored. That's not what serialization and deserialization is.

Comeback

There's so much to unpack here.

In short:

• Though "persistence with consistence" is part of what dol is about, it's more general than that: It's about creating purpose-specific data access objects on top of data sources/targets facading-away any non-purpose-specific particulars. Persistence is often one of these non-purpose-specific particulars.
• You don't think data should be transformed when stored, yet data is always (a very literal always) transformed. Serialization and deserialization are transformations.

I understand, though, that this subsuming perspective is hard to see at first. This critique has happened before. In fact, I recorded an actual (chat) conversation (changing the names) here, if you want to read further.