Masonry built with Swift Support about masonry HOT 19 CLOSED

I have been using Masonry (not Snappy) with Swift with success. Thanks to a clever fellow on StackOverflow, I got the syntax figured:

mediaCollectionView.mas_makeConstraints { (make) -> Void in
            var padding: UIEdgeInsets = UIEdgeInsetsMake(10, 10, 10, 10);
            make.edges.equalTo()(0).with().insets()(padding)
            return ()
        }

ie: some extra parentheses in the fluent syntax and optionally a return () to finish it off with. The return statement, however, does only seem to be required when there is a single line inside the closure. If there are two lines or more, it seems that the return () statement is not required (!) I guess this is due to the not-quite-mature state of the XCode 6 compiler/SourceKit. (or it could be me messing stuff up, also possible :-)

Hope this is useful.

from masonry.

@scmyers11 I've been thinking about doing a new swift version of the code base. There are a lot of things that could be tidied up using some of the features in swift

from masonry.

I absolutely love everything about what you just said.

from masonry.

However there is also a possibility of introducing a entirely new DSL since Swift supports operator overloading.

var view1 = View()
var view2 = View()

installConstraints([
    view1.right == view2.left + 10,
    view2.edges >= UIEdgeInsets(top: 10, left: 20, bottom: 10, right: 10)
])

This is actually code code that compiles. Did a proof of concept last night

from masonry.

👍 for DSL based on operator overloading. What could be better than actual constraint equations written down, plain and simple! This is exciting :)

from masonry.

@nickynick will try push something basic tonight to a new branch, let me know if you would be interested in collaborating :)

from masonry.

I will second the vote for the DSL based on overloaded operators. That makes total sense to me.

from masonry.

👍 for swift support

from masonry.

New DSL sounds good, although I'm going to miss Masonry until that arrives :)

from masonry.

Swift FTW! 👍

As long as you don't use Emoji:
view1.➡️ == view2.⬅️ + 10
view2.↕️ ↔️ >= UIEdgeInsets(top: 10, left: 20, bottom: 10, right: 10)
haha

I'm still reading the book but I think it opens a lot of possibilities to Masonry :)

from masonry.

@cloudkite Sure, count me in :)

from masonry.

Hey guys there is a very rough non-working prototype at https://github.com/cloudkite/Masonry/tree/expressive_swift

Unfortunately work is really busy at the moment so I can't see myself being able to bring this to fruition any time soon. If anyone is keen to take this code/ideas and run with it, ie create their own repo etc. That would be awesome and I would try help out and contribute as much as time permits.

from masonry.

@cloudkite Do you think we better have this stuff in a brand-new repo and leave Masonry as is? Maybe, since Masonry is already quite popular, we could just have a separate Swift codebase right here, and have different podspecs for each. Both Obj-C and Swift codebases can still share some concepts, I suppose.

I'm really eager to work on this, can't wait until Saturday. Could you grant me a push access, perhaps? :)

from masonry.

I think a new repo would make alot of sense as the DSL will probably be quite different to Masonry.

I have transferred Masonry to a Masonry organisation and setup a new repo is up here https://github.com/Masonry/Snappy if anyone has suggestions, ideas etc please raise them there. Also ideas for a better library name are most welcome!

@nickynick you should have push access now, go nuts ;)

from masonry.

@nickynick @cloudkite It really depends on whether or not the Swift codebase API works in Objective-C. If it doesn't than it's going to be best to keep it separated.

I'm working on some crazy stuff in my own code at the moment, I think a lot of the complexity around Masonry can be deduced massively thanks to extensions.

from masonry.

For anyone still waiting, https://github.com/Masonry/Snappy is ready for use now. It's a preview release so it probably has some bugs and it has some features missing such as updateConstraints but if you’re dying for Masonry in your Swift project you can grab it and it should work for you with identical API but more type safety!

from masonry.

Good news :)!

On Tue, Jul 29, 2014 at 1:07 PM, Robert Payne [email protected]
wrote:

For anyone still waiting, https://github.com/Masonry/Snappy is ready for
use now. It's a preview release so it probably has some bugs and it has
some features missing such as updateConstraints but if you’re dying for
Masonry in your Swift project you can grab it and it should work for you
with identical API but more type safety!

—
Reply to this email directly or view it on GitHub
#75 (comment).

from masonry.

@joachimboggild
In swift
like in groovy or Ruby
or many dynamic langage
Return is facultatif, the last expression is used as a return value.
But it seems that swift compiler check that. I saw him with warning like "Return keyword is useless with a ()->Void"

from masonry.

@joachimboggild That's amazing, thank you

from masonry.