Extract the MTLModel protocol #219
Conversation
|
I'm not opposed to this idea, but how would we do things like "default implementations" in this design? What happens to methods like |
Mantle/MTLModel.h
Outdated
| // | ||
| // 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 |
There was a problem hiding this comment.
This is more of an implementation detail slash convenience of MTLModel the class and should go there accordingly.
|
It would be the responsibility of the respective class to fulfil the contract of 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 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 |
Mantle/MTLModel.h
Outdated
| // 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. |
There was a problem hiding this comment.
This probably should be reworded so that it becomes part of the contract that nil values should map to NSNull.
|
Why does the class need to be renamed to fulfill #167? Naming the class and the protocol |
|
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 |
|
We could change the name of the class from @interface XYModel : MTLModel
// …
@end |
|
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? |
|
Ah, sorry, misread what you said. If we stick with If we want to break everybody's build when they upgrade to |
|
We'll probably have enough breakage no matter what. Seriously, though, I'm most interested in Doing Things Right™—I think that's the |
Conflicts: Mantle/MTLManagedObjectAdapter.m MantleTests/MTLTestModel.h
|
Improved some of the documentation |
Mantle/MTLJSONAdapter.m
Outdated
| @@ -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]; | |||
There was a problem hiding this comment.
Accidental extra space here.
|
🎎 |
|
Let me know what you think of this protocol introduction. |
|
Documentation looks ✨. Just the open comment threads now. |
|
📟 |
|
merging |
Conflicts: Mantle/MTLModel.h MantleTests/MTLTestModel.h MantleTests/MTLTestModel.m
|
merged |
MantleTests/MTLTestModel.h
Outdated
| // Conforms to MTLJSONSerializing but does not inherit from the MTLModel class. | ||
| @interface MTLConformingModel : NSObject <MTLJSONSerializing> | ||
|
|
||
| - (instancetype)initWithDictionary:(NSDictionary *)dictionaryValue error:(NSError **)error; |
There was a problem hiding this comment.
This doesn't need to be declared publicly unless it's being used in tests.
|
☎️ |
|
📱 |
|
📲 |
Extract the MTLModel protocol
|
Is this going to be released soon? |
|
@priteshshah1983 This is currently part of the in-development 2.0 version of Mantle (occurring on the |
This extracts the core interface of
MTLModelinto 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
MTLModelinto the inheritance chain may not be an option or whenMTLModelshould 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
MTLModelclass 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
MTLModelclass implementation and should be updated accordingly.