Rename lens getter/setter about cycle-onionify HOT 8 CLOSED

I'm not a friend of this. Elm does it a lot. Renaming standard FP vacabulary to be better understood. The flipside is, when googling you wont find answers for the topic you are searching and once you move to other FP languages/libraries younare confused with the terminology. I would rather explain this in the docs

from cycle-onionify.

I think this change would make it easier to explain Onionify lenses to folks who haven't already been exposed to this and other FP concept much.

from cycle-onionify.

On second thought @ntilwalli is right that fromParent/toParent might be clearer than zoomIn/zoomOut. After all Lens is defined in onionify, so it makes sense that the names reflect the way the functions are used in onionify. Another option is a mixed toChild/toParent.

While we're at it we should also think of fitting parameter names, which are helpful when autocompletion works. E.g. toChild(parentState) / toParent(prevParentState, childState).

from cycle-onionify.

I'm not a fan of zoomIn and zoomOut as terms. fromParent and toParent make more sense to me if anything (or toChild/fromChild), but I'm also okay with get/set as well. Just my two cents.

from cycle-onionify.

Renaming standard FP vocabulary to be better understood.

It would be useful to clarify Cycle's position regarding this. For what I've seen @staltz tends to prefer self-explanatory over standard vocabulary. Am I right?

@jvanbruegge has a point in that standard vocabulary may actually be more beginner-friendly than self-explanatory language, because the former is more googleable. However where OO and FP vocabulary overlap I think it's important to disambiguate by adopting new terms for the FP concepts. That's because OO is the common ground among programmers, especially JS programmers.

My personal experience with FP is that it's still not second nature for me. I may fully understand a FP concept when I read the theory, but then in my daily job it sometimes mixes up with OO. (OO is a bad disease). In the case of lenses there's a danger that beginners understand set to update some value inside the lens, as if it were an object. By contrast, zoomIn and zoomOut read more like capabilities of the "lens" tool, which reveal themselves depending on how you "flip" the lens. In any case, it would be helpful to provide a new word for each new concept. In order to help with googling, the docs can provide a translation to standard FP language.

I'm not convinced by @ntilwalli's fromParent / toParent as it fits more the specific use of lenses in onionify than the lenses themselves.

from cycle-onionify.

Thanks @jvanbruegge and @ntilwalli for the opposite views, I looked at the topic from a different lens (pun!) than before. Those are valid points.

When it comes to FP naming, it's true that I don't necessarily pick what has been established in Haskell, for instance. Take xstream fold, it's scan in Haskell. On one hand I don't want to rename everything just for the sake of renaming, on the other hand, Haskell is also a moving target when it comes to naming (e.g. they started using more "-able" words to describe type classes, like Traversable, Foldable, instead of borrowing from category theory: Monoid, Group, Semigroup, Functor, etc). I'm not in the Haskell circles, but my impression is that they stick to category theory names when it comes to those very natural type classes, and they take inspiration from computer science to name other type classes mostly related to programming.

I'd also like to point out differences in naming among hard-core FP too, like differences between Haskell and PureScript, and Fantasy Land (which is JavaScript), such as

• FL Monad uses the function name chain while typically it's "bind"
• FL Foldable uses the function name reduce while in Haskell and PureScript it's "fold"
• FL Semigroup uses "concat" while Haskell uses "mappend", and PureScript "append"
• FL Profunctor uses "promap" while Haskell and PureScript: "dimap"

My main concern with "getter" / "setter" is possible confusion with cyclejs/cyclejs#581 if we end up establishing push-pull Cycle.js on the basic concepts of getters and setters (see specially this comment or this talk by Erik Meijer). My secondary concern is what @abaco mentioned: possible confusion that set will mutate/update a hidden variable.

When it comes to web-searchability, I had actually initially thought about also renaming "Lens" to "Zooming" so it matches the method names too. But I noticed this renaming wouldn't help, because it would make searching "zooming" quite painful. If we keep "Lens", it is quite well searchable. Plus, Lens is a good name in itself, as a magnifying glass' function is to zoom. Actually I would imagine the name "Lens" plus "zoomIn" would help to search the web for Cycle.js specific lens. If you search "Lens getter" you get all sorts of Haskell content. If you search "Lens zoomIn" you would probably get Cycle.js content more easily.

About these renaming threads, I find them important to discuss and achieve a consensus. Usually we find a solution that everyone likes. I remember we took many comments to figure out the name isolate, back then.

from cycle-onionify.

👍

Also, some lens in other contexts have

set(childState, prevParentState): nextParentState

as signature.

from cycle-onionify.

Closed because of @ cycle/state

from cycle-onionify.