Oooh interesting! I hadn't considered calling back to the Obj-C version
from Swift land...

On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber <[email protected]> wrote:

> 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