Objectmapper: Protocols Not Serialising

[Megatron1000]

I have two objects, Cat & Dog both conforming to the Pet protocol. Pet inherits from mappable and Cat and Dog both implement the necessary methods to conform to it.

The array of pets is failing to show up when calling toJSON, with mapping set up as:
pets <- ["pets"]
An abstract superclass seems to work, so I'm assuming somewhere there's a check for AnyObject that's failing because it's an array protocols.

[juangamnik]

I think it is crucial to support protocols. I would like to embrace protocol-oriented programming and value types, but I need polymorphy and to serialize the values to disk. Currently, I use classes and NSCoding and a self-made copy() method... 😒

[txaiwieser]

Same case here, i have an array of transactions, and they are different objects, i made a protocol for transactions, but cannot make it to work. Any help?

[marioyohanes]

I have same issue with version 1.4.0, it simply skip protocol properties during mapping. I saw the issue being closed but couldn't found open ticket for this issue.

[juangamnik]

Is there any progress to this issue? I do not want to push anyone who puts his spare time into this project I just am unsure whether this bug stays open because it is low priority, hard to solve, or not an issue for most users.

[juangamnik]

If someone points me to the right place (in code) I could try to solve this issue ...

[tristanhimmelman]

I did a bit of investigation and noticed a few things.

Given a Pet protocol conforming to Mappable and the following mapping pets <- map["pets"], ObjectMapper has no way of knowing what type of object to instantiate during mapping. Pet(map: map) is not a valid call.

If Pet was a class, then you could use objectForMapping in StaticMappable to return the correct type of subclass during mapping.

With that said, I'm not sure how we can support serializing protocols

[juangamnik]

First off: I checked the Readme.md of this project for StaticMappable. There is a link to an example which leads to a 404.

If Pet was a class, then you could use objectForMapping in StaticMappable to
return the correct type of subclass during mapping.

Why is there a limitation to classes? You can have a struct implementing a protocol and a corresponding static function (at least my playground in Swift 3, Xcode 8 eats it).

If there is a deeper underlying problem, you could offer to add _mapping and init_ functions to some kind of (public) API method like this:

func addMapping(type: BaseMappable.Type, 
    objectRetriever: (Map) -> BaseMappable?, 
    mapper: (BaseMappable, Map) -> BaseMappable) { 
  /* register the mapping for the given type */ 
}

Client code could call it like this (simplified example I know):

addMapping(type: Dog.self,
    objectRetriever: { map in Dog() },
    mapper: {
        var copy = $0
        copy.mapping(map: $1)
        return copy
    }
)

Edit:
I see, this is not the problem at all. The issue seems to be, that the information, which Pet subtype has been used is not available during mapping, right? Why don't you just add an additional @type entry to your JSON, that stores this information during serialization? A lot of mappers use @id and @ref for structures with cycles, so using is to get the correct type to map to, shouldn't be a problem, should it? Or do I miss here something?

[juangamnik]

As a small follow-up: Don't you have the same "issue" with classes with inheritance hierarchy? If you have a base class Pet and a concrete sub class Dog and you have a property of type Pet which is "filled" with a Dog, serialize it, and deserialize it later on, you should deserialise a Dog not a Pet. So, if you do this already correctly, then you need type information in the JSON output.

[juangamnik]

Anything new on this? Did my information help (@id/@ref/@type)?

[chamander]

Why is there a limitation to classes? You can have a struct implementing a protocol and a corresponding static function (at least my playground in Swift 3, Xcode 8 eats it).

With a class, Swift has more type information with which it can work with. With a protocol, there is much less information to do so--it is unable to determine a single-type (even if generic T) at runtime.

This means that even in this context, where it calls Pet.objectForMapping(_:), the type information says that a Dog could return a Cat--even though we know, as developers, that this is not the case. As soon as we "expect" this form of polymorphism, the work we need to do to declare compile-time safety increases. To work with this, we can provide more type information and write:

public protocol GenericMappable: Mappable {

  associatedtype Mapped: Mappable = Self

  static func mapped(from map: Map) -> Mapped?

  func serialized() -> JSON // For some `ObjectMapper`-defined `JSON` type.

}

// Elsewhere, in an application-specific namespace.

internal protocol Pet: class {
  func makeSound() -> String?
}

internal class Dog: GenericMappable, Pet { ... }

internal class Cat: GenericMappable, Pet { ... }

internal class PetWrapper<T> where T: Pet {

  private(set) internal let wrapped: T

  init(wrapping pet: T) { wrapped = pet }

  func makeSound() -> String? { return wrapped.makeSound() }

}

This still means that we aren't able to drill down on the runtime type of instances of the conforming type without further introspection (because of the new associatedtype), but provided there is some functionality in Pet that we would like access to, this is still useful. Given there is some other way to retrieve the type information to use for the construction of the instance, we are able to use this.

@txaiwieser

Same case here, i have an array of transactions, and they are different objects, i made a protocol for transactions, but cannot make it to work. Any help?

This issue is related to that. i.e. That with a array of heterogenous types, the compiler does not have enough information on the underlying concrete type(s).

This issue is not apparent with classes because they share some type information--it gets complicated as soon as you inherit from some abstract superclass, however.

With the implementation above, the compromise we're likely to make is:

let collection: Array<Pet> = ... // Some pre-defined collection.

let serialized: Array<JSON> = collection.flatMap { ($0 as? GenericMappable)?.serialized() }

@tristanhimmelman , What do you think about this, having context of the implementation of ObjectMapper?

[juangamnik]

With a class, Swift has more type information with which it can work with. With a protocol, there is much less information to do so--it is unable to determine a single-type (even if generic T) at runtime.

You just need enough information to write out the concrete type during serialization and call the deserialization function for the correct type during load. So if the issue really is, to get the concrete type, adding a corresponding typeName-method to Mappable should do the trick. It willl be called polymorphically and used to write the corresponding information in a @type attribute (or something similar) in the JSON output, and use the same information to lookup the implementation (e.g. from some dictionary) in order to deserialize the correct type.

This means that even in this context, where it calls Pet.objectForMapping(_:), the type information says that a Dog could return a Cat--even though we know, as developers, that this is not the case.

If you have a property of type Pet, sure it might be a Dog or a Cat later on, this is why Pet is used. If I want to be sure, that I get a Dog, I will use a property typed with Dog. I don't get the point here.

[juangamnik]

You could even use the typename to control, which type is used later on by setting a concrete type in the registry/dictionary I mentioned.

[txaiwieser]

This is how I solved my initial problem, its not ideal, but it works 100%.

transactions <- (map["transactions"], TransactionSerializationTransform())

class TransactionSerializationTransform: TransformType {
    typealias Object = Transaction
    typealias JSON = [String: AnyObject]

    init() {}

    public func transformFromJSON(_ value: Any?) -> Transaction? {
        guard
            let json = value as? JSON,
            let typeString = json["type"] as? String,
            let transactionType = FinalTransactionType(rawValue: typeString)
            else { return nil }

        switch transactionType {
        case .deposit:
            return Mapper<Deposit>().map(JSON: json)
        case .invoice:
            return Mapper<Invoice>().map(JSON: json)
        case .withdraw:
            return Mapper<Withdraw>().map(JSON: json)
        }
    }

    func transformToJSON(_ value: Object?) -> JSON? {
        assertionFailure("Not implemented")
        return nil
    }
}

[juangamnik]

Anything new on this?

[airslider]

extension ImmutableMappable {

    static func transformer() -> TransformOf<Self, [String: Any]> {

        let transform = TransformOf<Self, [String: Any]>(fromJSON: { (value: [String: Any]?) -> Self? in
            guard let value = value else {
                return .none
            }
            do {
                let obj = try Mapper<Self>().map(JSON: value)
                return obj
            } catch {
                Tracker.log(error)
                return .none
            }
        }, toJSON: { (value: Self?) -> [String: Any]? in
            if let value = value {
                return value.toJSON()
            } else {
                return .none
            }
        })

        return transform
    }
}

use

let avatar: AvatarModel?

    required init(map: Map) throws {

       ...
        avatar = try? map.value("avatar", using: FirestoreAvatarModel.transformer())
    }