microlens instead of lens for lighter installation ? about brick HOT 9 CLOSED

I have thought about doing this very thing. I even want to have the lens-style API confined to a separate brick-lens package. But even if I switched to another lens implementation, it wouldn't save any time because vty uses lens. I have approached Corey about removing the lens dependency from vty so I can achieve the same with my library. Please pile on at jtdaugherty/vty#90

from brick.

On second thought, putting all the lens support in a separate package would be annoying to me because I'd always want it, so let's leave the lens API in the main package. However, I would be happy to port to microlens (provided its API is big enough). I am not sure when I'll have time to get to it, but I would be happy to consider patches to this effect. :)

from brick.

A big part of this port would also be to carefully look over the User Guide to ensure that it mirrors the lens API.

from brick.

microlens does mirror the lens API, yep. I just noticed that I didn't have a migration guide for microlens, so I wrote one.

I looked at your code and I think it's possible for you to migrate. The only complication is going to be this – you define your own instances of Field1 and Field2, but lens's Field1 does not equal microlens's Field1 and so users who import Control.Lens won't be able to use _1/_2 with Location. If you don't intend your users to use them anyway, it's okay – but otherwise you might have to rename them to e.g. rowL/columnL.

from brick.

The ticket jtdaugherty/vty#90 is now closed, so when I get time I'll migrate brick to microlens (and cut a new release of vty).

from brick.

This is now done and released:

http://hackage.haskell.org/package/vty-5.5.0
http://hackage.haskell.org/package/brick-0.6

from brick.

And now hledger-ui installs quicker (at least 9 fewer deps). Thank you!

from brick.

Fantastic!

from brick.

@neongreen - thanks for writing that guide!

from brick.