Separation of read/write accessors

[mindplay-dk]

Have you given much thought to "conjoined" vs separate read/write accessors?

ChatGPT can sum up the differences nicely:

https://chatgpt.com/share/488d61e1-577b-42bd-a19e-63a81c16dff0

The pros for seperate functions that I like to highlight are:

Clarity and Explicitness: With separate functions, it’s clear which function is used for reading and which is for updating. This explicitness can reduce cognitive load, especially for newcomers to the codebase.

Better Type Safety: In languages with strong type systems (or with TypeScript), separating getter and setter functions allows for more precise type definitions. The getter can be typed as returning a value, and the setter can be typed as accepting a value, reducing the risk of type-related errors.

And the main problem with a single function:

Ambiguity: It can sometimes be less clear at a glance whether the function is being used to get or set the value, especially in more complex code. This might lead to some confusion when reading the code, particularly for new developers or during code reviews.

This one is important - skimming over code where read and write operations look very similar requires more mental parsing.

The only real down side (from my perspective) is this:

Slightly Less Concise: In cases where minimal code is important, separate functions can feel less elegant or concise compared to a single function.

I don't find this difference is important enough to put up with the ambiguity, but of course YMMV. 😄

Popular frameworks like Solid are kind of setting the tone for this important detail. I was an early adopter of Sinuous - and I loved it, but I now definitely prefer the approach that Solid takes. Ryan had an article at some point talking about this, but I can't seem to find it now. (it might have been just something he talked about in one of his very long streams.)

I'm generally opposed to function overloading and feel quite strongly about this - it's one thing to have one function performing the same (or very similar) operation on two different types of input, but it's another to have one function perform two very different (event opposite) functions. I like brevity as much as the next guy, but not at the expense of clarity - being able to scan the source code (visually) is very important, and the implications of reading versus updating state are critical.

I was also very excited about Haptic and the idea of making things more visible, and hence my interest in your project, so I'd expect maybe we have some of the same opinions on this stuff.

Just wondering how much consideration you gave to this issue?

Cheers. 🙂

[abhishiv]

Hey @mindplay-dk

Thanks for starting this discussion. You are the second person who has told me this, and I have heard ryan solid also mention that in his experience developers much prefer the new solid style of signal destructuring compared to old style.

This one is important - skimming over code where read and write operations look very similar requires more mental parsing.

TBH I didn't give much consideration to this issue since I just wanted to get something working out of the window that I could start using in production. I'm building @gratico using alfama which now has a decent size codebase, and I would agree alfama has some issues in DX and it's not as polished as solid/react in that respect. But I'll try to improve it starting with this issue.

Btw, I do remember reading your comment on haptic about dipole nettyso/haptic#5. That's a style I would like to implement for store cursors when I get time. What do you think about that?

I also like that Dipole's observables make reading and writing explicit with .get() and .set(value) methods - it requires slightly more work on the keyboard, but makes it much easier to skim through a large chunk of code and spot where the reads/writes are taking place. Opinionated, but readable code is more important than writable code: you only have to write it once, but you have to read it many times, your coworkers have to read it, and so on.

[mindplay-dk]

TBH I didn't give much consideration to this issue since I just wanted to get something working out of the window that I could start using in production. I'm building @gratico using alfama which now has a decent size codebase, and I would agree alfama has some issues in DX and it's not as polished as solid/react in that respect. But I'll try to improve it starting with this issue.

cool! this project looks promising, I'm excited to see where this goes. 🙂

Btw, I do remember reading your comment on haptic about dipole nettybun/haptic#5. That's a style I would like to implement for store cursors when I get time. What do you think about that?

I also like that Dipole's observables make reading and writing explicit with .get() and .set(value) methods

Looking back at this comment, while, yes, I really prefer the presence of words to cryptic symbols, well, two things:

1. this approach has the same problem of not providing read/write segregation - that is, you get one object with two methods, which has one of the same problems as having one function with two responsibilities, namely that it's tempting to pass them around together. This is honestly not something I feel strongly about myself, but I've debated Ryan on this point many times over, and what I can say is, he appears to have strongly founded reasons why he thinks this is approach is bad - and there is no question he has spend way more time on this design issue than I have, so, honestly, I would defer to Ryan on this.

2. in terms of balancing verbosity, explicitness, and conciseness, this is one step further in the direction away from the extreme terseness of a single overloaded function - it's a longer departure in that direction. Perhaps rather than letting the pendulum swing in the opposite direction, it's safer to try to hit some middle ground? I think that's in part what Ryan is trying to do.

In terms of readability, I am fine with destructuring a tuple - I was just this morning arguing for the same thing here, so I guess I've come around on this topic. I used to think "tuples are bad", but now I just view than as the idiomatic "multiple return" pattern in JS - clearly React and Solid have influenced my view here, but given that JS doesn't have multiple return, tuples appears to be how the community has settled on doing that.

Using the tuple destructuring pattern for things like state management is idiomatic enough at least in the world of UI libraries by now that it's probably the conventional, safe and expected way to do it? 🙂