Recursive scope intuition gap

[barneycarroll]

Situations exist where an S is desirable because higher-level property querying is necessary to compute the patch, but a PS is nonetheless the most intuitive way to compose the return object.

Eg:

PS(model => {
  const newThing = operateOn(model.thing1)

  return P(model, {
    thing1: PS({ derivedThing: newThing }),
    thing2: newThing,
  }) 
})

In overload mode, this is more intuitively expressed as

O(model => {
  const newThing = operateOn(model.thing1)

  return O({
    thing1: PS({ derivedThing: newThing }),
    thing2: newThing,
  }) 
})

*

But this won't work, because the higher order scope has already been unwrapped for the containing object: the returned value is assumed to be the desired end value and the model will be corrupted with an interstitial scope entity.

The intuition gap raises the problem of assuming interstitial entities will at some point get converted by a higher order P, without thinking too much about when and how this stuff happens (which is kind of the selling point).

Should it be discouraged, as a smell of a bad model or model interaction paradigm? Is that any of my business?

Would tweaking scope application to be recursive lead to other footguns?

Hmmm.

---

• or, perhaps ;P

  O((model, newThing = operateOn(model.thing1)) => 
  O({
  thing1: PS({ derivedThing: newThing }),
  thing2: newThing,
  }) 
  })

[foxdonut]

Interesting..

FWIW, when I had to convert a temperature value to a different unit (between C and F), using Patchinko I found it relatively intuitive that from O(x => y) I had to return y as the "final" value

flems

Cheers Barney. I am loving Patchinko, thanks for writing it!

[barneycarroll]

That's gorgeous! I really like the way three essential mechanisms (MVC in the old days) — control, model interaction, and view — look visibly different, and yet succinct. It's no longer the accepted compromise of loads of different generic utility functions everywhere or the alternative of highly elaborate custom APIs for binding them together.

I'm so glad this is coming together. I knew Meiosis was the correct principle behind a pervasive nightmarish class of problem, but I'm still grokking the deeper implications of how nested model changes can be made to work intuitively without a debt of baggage of custom boilerplate. And I've been convinced for a shorter period that Patchinko could deal with all the lense-ish problems… So that Meiosis could stay slim and principled as long as a good shoe-horn existed for all the concerns of how to tunnel through to, query, modify objects. All that stuff is a different order of problem, it shouldn't be Meiosis' burden to equivocate on opinionated ways of dealing with the conceptually bog-simple task of querying simple state objects.

So thanks for investing in this concept, I'm really glad you're seeing it work.

I think we're just scratching the surface. Great things are coming!