so one could probably migrate UI classes using it bit by bit.
But the new all-Swift version in Snap apparently has a cleaner syntax
that fits with Swift better...
Actually, do they conflict? Could we start with one in Obj-C and
transition to the Swift one in Swift classes, while both sit in place? In
theory they're creating regular layout constraints so it's just the setup
calls that are different...
-- brion
On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd <mhurd(a)wikimedia.org> wrote:
I found this Swift version of Masonry:
https://github.com/Masonry/Snap
Are we confident in it, or does anyone know if the original Masonry
repo maintainers have Swift plans?
If not, assuming one of our long-term goals is to eventually convert as
much of the codebase to Swift as is practical, wouldn't adopting Masonry
further entrench Obj-C implementations?
i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry
syntax back to VFL strings and/or NSLayoutConstraints.
If there's not a solid Swift implementation, I'd be unsure if Masonry
use is wise strategically. Thoughts?
Any concern that Masonry's syntax, while concise/elegant, raises the
bar for outside contributions in that it deviates from the "standard"
approach at all?
On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle <bgerstle(a)wikimedia.org
> wrote:
> +1
>
> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <cfloyd(a)wikimedia.org>
> wrote:
>
>> We were evaluating Masonry prior to our new 3rd party lib vetting
>> process (See here for more info:
>>
https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries),
>> but still wanted to do a write up for everyone.
>>
>> Masonry is a library that allows developers to write autolayout code
>> similar to the Visual Format Language, but instead of error prone strings
>> to describe relationships, it provides a compact compiler checked syntax.
>> You can read more here:
>>
https://github.com/Masonry/Masonry
>>
>>
>> Below are answers to our standard questions:
>>
>>
>> - Is the license permissive?
>>
>> Yes - MIT
>>
>> - Is the library ubiquitous?
>>
>> Yes 4,362+ stars and 475 forks on Github.
>>
>> - Is it installable via CocoaPods?
>>
>> Yes
>>
>> - What is the impact on binary size?
>>
>> Negligible - no included assets
>>
>> - How severe, if at all, are inbuilt subdependencies?
>>
>> No 3rd party dependencies
>>
>> - Will this make the code more, or less, understandable for
>> volunteers?
>>
>> More understandable - it provides an expressive "english" syntax for
>> creating autolayout constraints. It introduces no new concepts, just type
>> checking and syntax.
>>
>> - What are the performance ramifications of using this library?
>>
>> None, it uses cocoa autolayout under the covers.
>>
>> - What are the complexity ramifications of using this library?
>>
>> Masonry allows developers to write layout code in a much more concise
>> and expressive way - this should reduce number of lines while increasing
>> expressiveness.
>>
>> - Is it actively maintained?
>>
>> Yes and receives frequent pull requests.
>>
>> - Is it compatible with current deployment targets?
>>
>> Yep
>>
>> - Does it hinder interop (e.g., with Swift)?
>>
>> Nope
>>
>> - What is the exit plan if the library becomes unmaintained?
>>
>> Since Masonry is basically just a syntax veneer of autolayout - it
>> should be possible for us to maintain if needed. There aren't any foreign
>> concepts to understand. If we choose not to maintain - the constraints can
>> be translated to the VFL language (or Interface Builder) easily.
>>
>>
>>
>> If anyone has questions / comments - please reply here.
>>
>>
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>>
https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
>
> --
> EN Wikipedia user page:
>
https://en.wikipedia.org/wiki/User:Brian.gerstle
> IRC: bgerstle
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l