Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract the MTLModel protocol #219

Merged
merged 14 commits into from
Mar 14, 2014
Merged

Extract the MTLModel protocol #219

merged 14 commits into from
Mar 14, 2014

Conversation

robb
Copy link
Member

@robb robb commented Jan 22, 2014

This extracts the core interface of MTLModel into a protocol of the same name and changes the adapters to use that instead.

This gives users of the framework a greater flexibility when integrating with existing code bases where injecting MTLModel into the inheritance chain may not be an option or when MTLModel should not be exposed as a super class. (See for example #156). For existing users, it's business as usual.

Since having a class and a protocol of the same name may be confusing, I'm all for other names for the protocol or even considering to change the name of the MTLModel class to break everybody's build (See #167).

This is just a proof of concept. Some of the documentation in the protocol still refers to implementation details of the MTLModel class implementation and should be updated accordingly.

@jspahrsummers
Copy link
Member

I'm not opposed to this idea, but how would we do things like "default implementations" in this design? What happens to methods like +propertyKeys, -dictionaryValue, and our default <NSCoding> behaviors?

//
// This property must never be nil.
@property (nonatomic, copy, readonly) NSDictionary *dictionaryValue;

// Merges the value of the given key on the receiver with the value of the same
// key from the given model object, giving precedence to the other model object.
//
// By default, this method looks for a `-merge<Key>FromModel:` method on the
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more of an implementation detail slash convenience of MTLModel the class and should go there accordingly.

@robb
Copy link
Member Author

robb commented Jan 23, 2014

It would be the responsibility of the respective class to fulfil the contract of +propertyKeys and -dictionaryValue. I am not sure if the rest of Mantle actually makes use of the assumption that NSCoding is implemented, so that may or may not be optional.

In the near term, I see this mostly as a way to make Mantle more adaptable to existing inheritance chains where you'd like to use MTLJSONSerializing or mix-and-match with MTLModel subclasses. I recently subclassed SKSpriteNode and friends–which already implement NSCoding– and something like this would've been quite handy.

I think the fact that this proof of concept was such an easy search-and-replace operation goes to show that there is good encapsulation in place, codifying this could help maintaining that in the future.

Having both MTLModel the protocol and MTLModel the class seems to get hairy quite easily. What's your thought on naming the class MTLObject with regards to #167?

// This is the designated initializer for this class.
- (instancetype)init;
// The default implementation combines the values corresponding to all
// +propertyKeys into a dictionary, with any nil values represented by NSNull.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably should be reworded so that it becomes part of the contract that nil values should map to NSNull.

@jspahrsummers
Copy link
Member

Why does the class need to be renamed to fulfill #167? Naming the class and the protocol MTLModel would make a lot of sense to me, if we can accomplish it.

@robb
Copy link
Member Author

robb commented Jan 31, 2014

It doesn't need to, but it would certainly break everybody's build 🚎
Since there is already some confusion how MTLModel doesn't handle JSON by itself, I'd rather call them something different. Calling the protocol something else would work just as well for me, but I don't have an idea right now.

@jspahrsummers
Copy link
Member

It doesn't need to, but it would certainly break everybody's build

Sorry for being obtuse, but I don't fully understand the ways in which it would break builds. Don't we have the same methods implemented on MTLModel the class in the end (even if they're declared in the protocol)?

@robb
Copy link
Member Author

robb commented Feb 3, 2014

We could change the name of the class from MTLModel to e.g. MTLObject, that would break every

@interface XYModel : MTLModel
//
@end

@jspahrsummers
Copy link
Member

Right, so my question was: if the class name stays the same—and some methods get declared in a protocol instead—in what way would builds break? Why would it affect existing code?

@robb
Copy link
Member Author

robb commented Feb 3, 2014

Ah, sorry, misread what you said.

If we stick with MTLModel for the class, everything should be fine, no matter what we call the protocol. 🍑

If we want to break everybody's build when they upgrade to 2.0 so we can make sure they follow our upgrade guide, then this may be a good opportunity to rename MTLModel the class.

@jspahrsummers
Copy link
Member

We'll probably have enough breakage no matter what. :trollface:

Seriously, though, I'm most interested in Doing Things Right™—I think that's the MTLModel name for the class and protocol. MTLObject reminds me of scary general-purpose frameworks, like Omni's Foundation.

Conflicts:
	Mantle/MTLManagedObjectAdapter.m
	MantleTests/MTLTestModel.h
@robb
Copy link
Member Author

robb commented Feb 27, 2014

Improved some of the documentation

@@ -187,13 +185,13 @@ - (id)initWithJSONDictionary:(NSDictionary *)JSONDictionary modelClass:(Class)mo
}
}

_model = [self.modelClass modelWithDictionary:dictionaryValue error:error];
_model = [[self.modelClass alloc ] initWithDictionary:dictionaryValue error:error];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accidental extra space here.

@jspahrsummers
Copy link
Member

🎎

@robb
Copy link
Member Author

robb commented Mar 13, 2014

Let me know what you think of this protocol introduction.

@jspahrsummers
Copy link
Member

Documentation looks ✨. Just the open comment threads now.

@robb
Copy link
Member Author

robb commented Mar 14, 2014

📟

@robb
Copy link
Member Author

robb commented Mar 14, 2014

merging

Conflicts:
	Mantle/MTLModel.h
	MantleTests/MTLTestModel.h
	MantleTests/MTLTestModel.m
@robb
Copy link
Member Author

robb commented Mar 14, 2014

merged

// Conforms to MTLJSONSerializing but does not inherit from the MTLModel class.
@interface MTLConformingModel : NSObject <MTLJSONSerializing>

- (instancetype)initWithDictionary:(NSDictionary *)dictionaryValue error:(NSError **)error;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need to be declared publicly unless it's being used in tests.

@jspahrsummers
Copy link
Member

☎️

@robb
Copy link
Member Author

robb commented Mar 14, 2014

📱

@jspahrsummers
Copy link
Member

📲

jspahrsummers added a commit that referenced this pull request Mar 14, 2014
@jspahrsummers jspahrsummers merged commit c7ffb81 into 2.0-development Mar 14, 2014
@jspahrsummers jspahrsummers deleted the model-protocol branch March 14, 2014 01:08
@priteshshah1983
Copy link
Contributor

Is this going to be released soon?

@jspahrsummers
Copy link
Member

@priteshshah1983 This is currently part of the in-development 2.0 version of Mantle (occurring on the 2.0-development branch). We haven't yet created plans around releasing it, since it's still actively being worked on and changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants