Breaking Objective-C language conventions

[miklselsoe]

I love Masonry to bits. It makes a ton of difference for me and enjoy using it on a daily basis. In that light I'd like to offer some constructive feedback.

I have an issue with the implementation: The MASConstraintMaker design and syntax violates basic Objective-C conventions. Obj-C properties are used in ways they were not intended to be used. I think it's wrong to fight the language because although immediate readability may increase, it decreases implementation transparancy; the implicit conventions and expectation management between an API developer and the API user vanishes and it generally clutters the code if developers create their own conventions instead of following the ones given by the language. Moreover, you're not only fighting the language, you're also fighting the IDE.

Of course, this is what I'm talking about:

[someView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.left.equalTo(otherView).with.offset(someOffset);
}

• The object 'make' is a verb. Object names should be nouns as their classes to indicate their role
• 'left' is a property representing a constraint. It is vaguely named to increase readability but doesn't tell me what it is.
• equalTo() can't really be considered a property although it's defined as such. It relates two objects (left and otherView) which is not the job of a property.
• 'with' does nothing other than increase readability of the 'sentence' and it's a property on the 'equalTo' object. By now I've lost track of what kind of objects I'm actually working on.
• etc...

Instead I suggest a syntax more like this:

[someView mas_makeConstraints:^(MASConstraintMaker *maker) {
    [maker setLeftEqualTo:otherView withOffset:someOffset];
}

Of course this would require a lot of new methods to cover all cases, but I think its more in line with language conventions and any Objective-C programmer with minimal experience will read this just as easily as the current syntax. An added benefit is that this syntax autocompletes much nicer in Xcode because you don't have to interrupt the auto completion with dots all the time.

I'd just like to start a discussion regarding this issue. I hope we can come up with a great solution that is more in line with the Obj-C language conventions while maintaining Masonry's simplicity and elegance.

[cloudkite]

Thanks for the feedback! Yes I debated over this when designing the API, however the sheer number of methods that would be required to get the same functionality that could be provided throught dot notation made me decide breaking convention was worthwhile in this particular case.

[smileyborg]

@miklselsoe For what it's worth, UIView+AutoLayout is basically the API you would get when approaching the same issue (making Auto Layout easier to code) with the approach you're advocating. Masonry is an awesome and fantastic project, but I decided to build UIView+AutoLayout specifically because I wanted to offer an API driven by some different underlying design decisions. There are most definitely pros and cons to both approaches.