It looks like it is possible to use the Obj-C version from Swift:

https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720

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 <[email protected]> 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 <[email protected]>
> wrote:
>
>> +1
>>
>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <[email protected]>
>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
> _______________________________________________
> Mobile-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Reply via email to