add mapview() support

[aplavin]

I really like this feature, and how simple it was to implement!
Transparently set values on mapped array views (from SplitApplyCombine.jl) when the mapping function is an optic.
The simplest example from tests:

X = [(a=1, b=2), (a=3, b=4)]
Y = mapview(@optic(_.b), X)
@test Y == [2, 4]
Y[2] = 100
@test X == [(a=1, b=2), (a=3, b=100)]

Haven't noticed before that Accessors.jl already uses Requires, which makes this addition possible without extra dependencies.

[jw3126]

The feature is very neat, but this is type piracy. One possibility would be to create a zero dependencies package AccessorsBase that just contains something like

function set end

and ask @andyferris if we can add the Base.setindex! overload at SplitApplyCombine.

[aplavin]

That would also be piracy: all these methods, at least https://github.com/JuliaObjects/Accessors.jl/blob/master/src/functionlenses.jl

[aplavin]

Maybe, "pirating" a method that isn't defined, and won't feasibly be defined in the original library is fine? As I understand, the main concern is that piracy can change the behavior of unrelated code - here it's hard to imagine such a case. SAC.jl cannot really define setindex for an arbitrary mappedarray by itself.

[jw3126]

That would also be piracy: all these methods, at least https://github.com/JuliaObjects/Accessors.jl/blob/master/src/functionlenses.jl

That is fine by the

Sometimes, coupled packages may engage in type piracy to separate features from definitions

clause in the manual. If we overloaded UnsupectingPackage.set that would be a problem.

Maybe, "pirating" a method that isn't defined, and won't feasibly be defined in the original library is fine?

Fair enough. @andyferris do you think we can do this overload here?

[jw3126]

Maybe, "pirating" a method that isn't defined, and won't feasibly be defined in the original library is fine?

What can happen is that some other people think the same and provide overloads for Base.setindex!(::MappedArray...) Then a third package might have Accessors and the other package as transitive dependencies and get weird bugs.

[rafaqz]

Ok I just saw the growing Project.toml. Thats what people will look at to check dependencies.

Mostly everyone is moving away from Requires.jl because its a hack with serious ttfx overheads - it cant precompile.

See the recent breakup of ArrayInterface.jl for a prominent example.

[jw3126]

Accessors.jl getting heavy is a good point @rafaqz and getting rid of Requires.jl is also on my wishlist. Currently, we only need it to avoid depending on StaticArrays.jl .
Do you have a suggestion where stuff like this PR could live?

[rafaqz]

Well we really need conditional dependencies: JuliaLang/Pkg.jl#1285

What ArrayInterface.jl is doing and we're currently doing with GeoInterface.jl is making subpackages in the same repository, named as the combination of packages. Like ArrayInterfaceOffsets.jl or GeoInterfaceTables.jl.

Then other packages and users can choose their dependencies. Its pretty clunky but the best we have currently.

(also sorry I meant to put my initial comment in the main thread I commented from a phone)

[aplavin]

I'm also curious how the StaticArrays support in Accessors would look without Requires. Should this https://github.com/JuliaObjects/Accessors.jl/blob/master/src/staticarrays.jl file be put into a separate package that depends on both? The major issue then is that users wouldn't install it and will think that Accessors just doesn't support SVectors.

[rafaqz]

Yep that's the major unsolved problem that Requires.jl is patching over with a hack: users have to manually import glue packages.

The conditional dependencies issue I linked above is the solution, if it ever gets written.

But we have to be careful stuffing things into Requires.jl, it adds up to a lot of package load time accross the ecosystem. Everything in a require block has to be parsed and precompiled every time we use it, instead of once when packages are updated.