Rafael Schouten

Ok cool, I read this as `(context, result)` from `_.a` and `a=1`, `a=3`: ```julia getall(obj, optic) == [((a=1, b=10), 1), ((a=3, b=30),3)] ``` Maybe I misunderstand what `getall` is.

> #23 looks a bit over my head - not even talking about implementation, I don't fully understand the interface and usecases. > Extracting values with `Elements` and `If` is...

> That describes the whole Accessors.jl :) Maybe you miss the part about _arbitrary_ objects. Most of Accessors works on objects where you know a field name or some other...

I dont realy get what is different with your proposal to that PR or what you dont understand at this point 😆 It has to be able to replace Flatten.jl...

I don't know how `Elements` works really, but you can do things like this with arbitrary optics where `_[2].g` is: ```julia @getall (x[2].g for x in missings_obj if x isa...

"Get me every `Float64` in this thing" seems like incredibly generic functionality to me ;)

I mean its not really worth arguing over which appoach is more general or "arguably more specialised", Im not sure why that's relevent. I have never needed the thing that...

Ok hah. Maybe we are talking past each other? Sure, your proposal is generic in relation to other optics. But not in terms of the interaction with other packages, e.g....

But how does it set all the numbers in an object from a flat tuple? Setting is the hard part, getting is clearly trivial. (Your example is also trivial right?...

Getting can be inferrable and is in Flatten.jl, and get/set used to compile away in Flatten.jl before compiler changes killed that. Its still some nanoseconds (like ~50 maybe fir something...