tweetはどんどん複雑になっていて、 #890 のような仕様変更・追加で投稿APIのインターフェイスがどんどん変わっていってる。
この変化を吸収し、クライアントサイドバリデーションの仕組みを共通化するために、Messageクラスに新しいtweetを作成する機能を追加する。

例¶

# いままで
Service.primary.post(
  message: "魔剤ンゴ！？",
  receiver: toshi_a,
  replyto: parent_message,
  mediaiolist: [...]
)
# 新しいの
Message.new(
  user: Service.primary.user_obj,
  body: "魔剤ンゴ！？",
  receivers: [User.findbyidname('toshi_a'), ...],
  replyto: parent_message,
  attachments: [...]
).compose

利点¶

学習コスト低減¶

ReadとWriteのインターフェイスがMessageに統一されることで、フィールドの名前を知ることでTweetからの値の読み出し・投稿の両方が出来るようになり、覚えることが減る。

投稿前に情報を取得することが容易になる¶

Messageには現在でも、ツイートに関する情報を集めるためのメソッドがたくさん用意されているが、これを投稿前に利用しながら、バリデーションなどのユーザへの情報の提供ができる。
具体的には、文字列のどの範囲がURLとして扱われるか、hidden header, hidden footerはどこからどこまでかといった情報が提供できると思う。

懸念¶

IDがない¶

IDはTwitterが決定するので、新しく作成したインスタンスにはIDがセットされない。Messageを扱う多くの処理が、IDがあることを前提にしているので、後方互換性を保ってこれを行うのは難しいかもしれない。