Yeah we could swap them out when we need to pretty easily On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd <mh...@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 <bvib...@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 <mh...@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 <bgers...@wikimedia.org> >>> wrote: >>> >>>> +1 >>>> >>>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <cfl...@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@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
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
