This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.
It’s a metaphor.
Monocle: Optics Library for Scala
21–30 of 70 posts
Re: Monocle: Optics Library for Scala
#22This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.
Re: Monocle: Optics Library for Scala
#23This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.
This is why I read the comments before I click on the link. :)
Re: Monocle: Optics Library for Scala
#24Does the LSP provide clear autocomplete on what properties can be accessed on the bound _ ?
Asking as someone that doesn't use Scala at all, but has seen the hit-and-miss of some FP language LSPs.
Re: Monocle: Optics Library for Scala
#25This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.
Words can have many uses.
https://en.wikipedia.org/wiki/Optic_(disambiguation)
> In computer science, optics are a general class of bidirectional transformations
Re: Monocle: Optics Library for Scala
#26I haven't encountered this pattern before. Is there some more information on what problems this is designed to solve?
The problem most programmers would be familiar with is making an update inside a deeply nested immutable data structure. For example, suppose you want to update a user's billing address, and you have an immutable data structure that looks like this: user { billingInfo: { card, address }, name, subscription { level, expiration }, status { level, since } } The structure is immutable, so you can't make the update in pla…
Does it offer creating a mutable view on top of the immutable structure that can be used to accumulate a whole set of changes to later be materialized into a copy with the changes? (or to be used directly, at whatever cost would be required) That's something I've been wondering why it's not more of an established thing. It would basically be docker, but for in-memory reference graphs instead of filesystems.
Re: Monocle: Optics Library for Scala
#27Earlier quoted context omitted.
The problem most programmers would be familiar with is making an update inside a deeply nested immutable data structure. For example, suppose you want to update a user's billing address, and you have an immutable data structure that looks like this: user { billingInfo: { card, address }, name, subscription { level, expiration }, status { level, since } } The structure is immutable, so you can't make the update in pla…
Does it offer creating a mutable view on top of the immutable structure that can be used to accumulate a whole set of changes to later be materialized into a copy with the changes? (or to be used directly, at whatever cost would be required) That's something I've been wondering why it's not more of an established thing. It would basically be docker, but for in-memory reference graphs instead of filesystems.
You are perhaps looking for software transactional memory.
Re: Monocle: Optics Library for Scala
#28This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.
The name, monocle, also further misleads those expecting the physics topic. They actually have a nice logo with a lens and the lambda symbol which is often the symbol used for wavelength.
Re: Monocle: Optics Library for Scala
#29This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.
"this has nothing to do with classes, which in sociology and related fields are strata which society can be analysed as being divided into"
Re: Monocle: Optics Library for Scala
#30Earlier quoted context omitted.
The problem most programmers would be familiar with is making an update inside a deeply nested immutable data structure. For example, suppose you want to update a user's billing address, and you have an immutable data structure that looks like this: user { billingInfo: { card, address }, name, subscription { level, expiration }, status { level, since } } The structure is immutable, so you can't make the update in pla…
Does it offer creating a mutable view on top of the immutable structure that can be used to accumulate a whole set of changes to later be materialized into a copy with the changes? (or to be used directly, at whatever cost would be required) That's something I've been wondering why it's not more of an established thing. It would basically be docker, but for in-memory reference graphs instead of filesystems.
Immer does this for JS/TS.