Yeah we could swap them out when we need to pretty easily

On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd <mhurd@wikimedia.org> wrote:
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 <bvibber@wikimedia.org> 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 <mhurd@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@wikimedia.org> wrote:
+1

On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <cfloyd@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:


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@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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l



_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l




_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l




--
Corey Floyd
Software Engineer 
Mobile Apps / iOS 
Wikimedia Foundation