Messagekit: Renaming `MessageData` to `MessageKind`

[SD10]

~Currently, MessageType is the protocol we use to represent a message in MessageKit:~

public protocol MessageType {
    var sender: Sender { get }
    var messageId: String { get }
    var sentDate: Date { get }
    var data: MessageData { get }
}

~It has a property data of type MessageData which holds the information for the message:~

public enum MessageData {

    case text(String)
    case attributedText(NSAttributedString)

    // MARK: - Not supported yet
//    case audio(Data)
//    case location(CLLocation)
//    case photo(UIImage)
//    case video(file: NSURL, thumbnail: UIImage)
//    case system(String)
//    case custom(Any)
//    case placeholder
}

Proposal

~I think MessageType more accurately describes the current MessageData model so I'd like to change the name of MessageData -> MessageType.~

~This requires us to find a new name for the current MessageType protocol. I'd like to use Message but I'm concerned with reserving such a generic type name.~

~I've thought about MessageProtocol or MessageRepresentable but these names are too long for a type that will be used everywhere in the library.~

Conclusion:

MessageData -> MessageKind

Vote thumbs up or thumbs down 😃

[cwalo]

Message is suuuuch a common name that I'm wary about reserving it. Speaking for myself, such a change would require a refactor and Realm migration at a minimum.

[philippeauriach]

What about "Messageable" ? (inspired from "Codable" and such, which seams
to be the "swifty" way of naming protocols)

[sunshinejr]

The other option is MessageProtocol

[fbartho]

I like MessageProtocol over Message that’s too generic to me.

Alternate: MessageLike

[SD10]

@philippeauriach I've thought of Messageable but to me this sounds like something that is capable of receiving a message. Plus, we'd have to call it Messagable to follow Codable conventions 🐟.

It's probably going to become MessageProtocol TBH. After the feedback I won't be reserving the Message name.

I appreciate getting feedback on this one

[hemangshah]

What about MessageItem @SD10 ?

[Sherlouk]

Not keen on MessageProtocol I must say - MessageItem is good IMO

SingleMessage (reserving space for grouped messages)

_{Sent with GitHawk}

[SD10]

MessageItem is a good one @hemangshah. We could definitely consider using that. SingleMessage is good too though. I won't be doing a name change in this upcoming release

[SD10]

Not likely to change the name of the MessageType protocol at this stage. However, since 1.0 contains so many breaking changes, now would be the time to do this if ever.

We could rename MessageData -> MessageKind

cc @zhongwuzw. If you don't think it's worth pursuing you can just close this

[zhongwuzw]

I think it's necessary, sometimes I was misleading by the name of MessageData TBO 😅 , I like MessageType -> Messagable and MessageData -> MessageKind.

[SD10]

I agree on MessageData -> MessageKind. It's such a bad name, so confusing.

Messagable may not be the best name because it suggests some sort of behavior such as something that is capable of receiving messages.

I don't think we can change MessageType at this point. I'm just suggesting the MessageData change because it is smaller.

I'm already going to be the most hated framework maintainer after the next set of changes 😓 😓

[zhongwuzw]

@SD10 💯 not bad, we are moving in the right direction IMO.

[SD10]

Going to put this in 2.0 actually. I want to lessen the burden of migration. It's kind of a trivial change when put in another release.

[hyouuu]

I actually think since this is just a naming change, putting it into 1.0 reduces a mandatory change in 2.0 and just add 1 more step for the already big migration to 1.0 which seems fine to me, just 2 cents

[wdcurry]

Late to the game here but yes, MessageData is just bad, as is the use of *Protocol. Never been a fan of the *able paradigm either. I prefer simple. Given the library is about messages, i don't quite understand why there is hesitation to reserve Message as the main name. This is what the library is about. "Type" is what the attribute under discussion actually is, and in my opinion, that is what it should be: MessageType.

[SD10]

@wdcurry I pretty much agree but we decided that Message was too general for us to reserve. I had a similar problem with Firebase when they reserved the User type name. It was really frustrating so I've learned from that experience.

[SD10]

Done in #658