KTV。 新しいJSON

私の開発では、Java→Objective C→Swift、Web→Enterprise→Mobile、XML→JSONの複数の方向にいくつかの段階を踏まなければなりませんでした。 私はこの方法で15年以上、長い間、各段階で慎重に長引きました。 さらに進む必要があります。 モバイルアプリケーションの場合、何かを思いつくことができます（おそらくまだ気に入らないでしょう）。 なぜ変更するのですか？



さらに、一部のアプリケーションでJSONがあまり好きではない理由と、私の意見では、JSONを少し便利にするためにどのように変更できるのかを説明します。



私はすぐに、KTVをJSONの代替として考えていないことに注意する必要があります。 そして、決してJavaScriptでの使用を検討しません。 不便で間違っています。 一方、JavaScriptオブジェクト記述システムが他の言語で型付きデータを処理するために使用される状況も奇妙であり、修正したいと思います。



この形式を作成した最初の理由に興味がある場合は、 S2とKTV形式を作成した理由について読むことができます。

JSONの長所と短所

JSON自体は優れています。

• シンプル。 コメントがないことを感謝します。 それらが残っていると、メタ情報がそこにプッシュされ始め（JSONは非常に貧弱なため）、表記法はすぐにゴミに変わります。
• 表現力豊か。 XMLとは異なりますが、幅広いタスクに十分です。
• レコードよりもXMLよりも大幅に短い。

JSONの病気は物語から生まれます。 JavaScriptのeval(-)



が、操作に便利なオブジェクトを生成する必要がありました。 残念ながら、他の言語のevalは通常、動作が異なり（存在する場合）、言語自体が異なります。 この形式を非JavaScriptで使用すると、その欠陥が見えます。

• 引用符。 標準（標準として、 http ： //www.json.orgからテキストを取ります ）に従って、すべての名前を引用符で囲む必要があります。 たとえば、ネットワーク経由でデータを送信するためにJSONを使用する場合、これは過剰です。
• タイピングの欠如。 より正確には、型はありますが、文字列全体/数値/ true / false / nullです。 そして、配列を持つオブジェクト。 それだけです 日付も整数も小数もありません。 モデルを理解しやすくするために、オブジェクトを型でマークする方法はありません。
• オブジェクトを記録するための標準の欠如。 これにより、たとえば、内部にオブジェクトが混在する配列が作成される場合があります。 これを解析する必要があるとき-それは痛いです。
• リンクの欠如。 JSONでオブジェクトの階層構造を記述する場合、異なる場所から同じオブジェクトへのリンクが定期的にあります。 JSONは、最初の使用を参照することを不可能にします。 何かを発明するか、オブジェクト全体を繰り返す必要がありますが、これは構造のサイズと解析の複雑さにとって悪いことです。

JSONのように機能する形式を見つけることを試みました（理想的にはそれのスーパーセットになります）が、同時に上記の問題の一部またはすべてを標準的な方法で解決することができました。 YAMLが見つかりました。

ヤムル

Yamlは良いです。 それはほとんどJSONのスーパーセットであり、明確に定義され（ http://www.yaml.org/spec/1.2/spec.html ）、読みやすいです。 しかし同時に：

• 構造のネストはインデントによって決定されます。 情報を送信する場合、それらを削除できると便利です。 タブ愛好家も尊重されず、インデントはスペースにすぎません。
• YAMLは非常に複雑です。 多数の特殊文字、構造上の合意により、YAMLのサポートが複雑になり、パーサーが困難になります（YAML 1.2は7年前に登場しましたが、サイトのニュースによると、パーサーは依然として主に以前のバージョンをサポートしています）。

一般的に、YAMLは「行きませんでした」。 彼以外に、私は一般的なフォーマットを知りません。 突然あなたが知っている場合-書き込み、私は喜んで見ます。



それは私が得たものを提示する時間です。

KTV

Key-Type-Value。 この形式を呼び出します。



JSONで単純なオブジェクトを書きましょう。

 { "name": "Alex", "coolness": 3.1415, "isAProgrammer": true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

KTVでこれを書き換えると、次のようになります。

 { name: Alex coolness: 3.1415 isAProgrammer: true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何も変わっていないようです。 しかし、詳しく見てみましょう：

• 引用符は削除されました。 現在、キーまたは値に重要な文字列がある場合にのみ必要です。 通常の状況では、引用符は必要ありません。
• 行末のカンマは削除されます。 1行に複数の定義を記述する場合、それら（またはセミコロン）を設定できます。 しかし、従来の記録では、それらは省略できます。

最初と2番目の例はどちらも有効なKTVファイルです。 これは非常に重要です。なぜなら、標準のJSONをKTVパーサーに挿入でき、彼は喜んでそれを食べるからです。 また、たとえば、アメニティを利用できます。



タイプはどこにありますか？ 上記の場合、タイプは値から推測されます。 「Alex」は文字列リテラルであるため、名前のタイプは「string」、クールネスは「double」、isAProgrammer-「bool」です。 これらのタイプに加えて、「null」（別名「nil」、同僚への挨拶）、「int」、「color」もあります。 同じ例を作成しますが、型を完全に指定します。

 { name(string): Alex coolness(double): 3.1415 isAProgrammer(bool): true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネストされたオブジェクト/配列はまだここにあります。 追加あり：

• オブジェクトと配列の両方が型を持つことができます。 配列の場合、タイプは配列内の各オブジェクトの共通タイプです。 2つの異なるタイプ（文字列/数値、または異なるオブジェクト）を配列に入れることはできません。
• 配列またはオブジェクトのタイプは、解析時にこのオブジェクトまたは配列をキャストする必要があるクラスを示す場合もあります。 例：
  
  property(font): {name:..., size:...}
  
  
  
  
  
  フォントオブジェクトを示すことができ、そして
  
  property(point): [2, 3]
  
  
  
  
  
  認識時にポイントオブジェクトに変換できます。 原則として、ポイントをオブジェクトにすることもできます（小道具x、yを使用）が、なぜですか？ どこにあるかはすでにわかっています。

リンク、他のプロパティを参照する機能があります。 このようなもの：

 { property: value another: @property }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、いくつかの分岐オブジェクトの記録を短縮したり、単に定数を設定して、ファイルの他の部分でそれらを参照したりできます。 最初の機能は、オブジェクトの構造が重要でない場合にRESTで役立ちます。 2番目は構成ファイルにあります。



ミックスインのアイデアは、他の言語からも借用されています。 これらを使用すると、1つのオブジェクトを別のオブジェクトにアタッチできます。 これは継承と考えることができますが、継承はOOPからのものであり、動作は継承され、プロパティのみがあります。 だから、混ぜたほうがいい。

 { object: { a: ..., b: ...} object2(+object): { c: ..., d: ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、解析後のobject2には、独自のプロパティとオブジェクトからのプロパティの両方が含まれます。 つまり、a、b、c、およびdです。

コメント

コメントに抵抗できず、整理できませんでした。 //または＃で設定できます。 どちらのタイプのコメントもインラインであり、ブロックコメントはありません。

2番目のタイプ（八角形）にはわずかな問題があります。 実際のところ、色リテラルは、標準のCSSフォーム、つまり#rrggbbaaで設定することになっています。これは、コメントを記述するための現在のオプションと競合します。 したがって、おそらく、将来的にはCオプション（//）のみが存在するでしょう。

フォーマット作業

この形式は私のためであり、この形式のパーサーは2つの場所で必要です。

• S2にスタイル情報を保存する（ Ångströmスタイルシステムの開発）
• そのため、Swift上の独自のサーバーとその上のアプリケーション間の通信を改善できます。

したがって、Swift専用の形式を使用することを検討します。 原則として、形式は非常にシンプルで、どの言語でもパーサーを整理するのは難しくありません。



Swiftの問題により、KTVから/ KTVへのオブジェクトの本当に正しいロード/シリアル化ができなくなりました。 したがって、この形式を使用するプロセスは次のとおりです。

• モデルクラスが作成されます。 通常のクラス（注釈付きの@objc
  
  
  
  を含む）または構造体と同様。 各クラスはKTVGenerated
  
  
  
  プロトコルを実装する必要があります。
• ジェネレータを使用して、オブジェクトをロードおよびシリアル化できるこれらのクラスの拡張機能が作成されます。
• 生成されたものを使用して、KTVをオブジェクトに、またはその逆に（またはJSONから/に）変換します。

モデル構造は、たとえば次のようになります。

 public struct RootObject: KTVGenerated { var string:String //   var stringOrNil:String? // optional var int:Int //  var stringArray:[String] //  var stringDictionary:[String:Int] //   var object:ChildObject? //      private var _privateString:String //      private(set) var _privateSetString:String //  —  let _constantString:String //      }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての主要な機能がサポートされていることがわかります。

• タイプ（ジェネレーターがクラス拡張を正しく作成できるように、明示的に登録する必要があります。
• コレクション（配列および連想配列）。
• オブジェクト階層（他のモデルクラスへのリンク）
• シリアル化に関与しないプロパティ（これらは定数、プライベートプロパティ、およびプライベートセッターを持つプロパティです）

このようなパーサーの作成の歴史は、別の記事のトピックです。 構造とクラスを同時に維持するタスク、属性自体なしで属性を設定する方法、ファイル分析にリフレクションの代わりにSourceKitを使用する方法、カスタムマッパーの必要性（非標準の日付の解析など）。 パーサー自体は現在、積極的な開発のプロセスにあり、絶えず変化しています。 しかし、十分な関心がある場合-私はワーキングドラフトをレイアウトし、オプションについて議論します。

別のデータ形式の利点

https://xkcd.com/927/

JSONは、アプリケーション間でデータを転送するためのいわゆる形式です。 これは、JavaScriptでオブジェクトを記述するための形式です。 そして、私たちは常に完全に異なる目的でそれを使用し、オンとオフの両方で押し出します。



実行中のタスクにより適合したものに移る時が来たように思えます。 厳密なタイピングを備えた新しいSwift、サーバーからモバイルクライアントに頻繁に転送する必要のある複雑なデータ構造。 IDEで、コンパイル中および解析中に構文をチェックできる形式が必要です。 そして、KTVは、基本的に構造を変更することなく、実質的に既に知られている形式を複雑にすることなく、いくつかの便利な小さなものを追加するように思えます。



実験的なソースコードを簡単な説明で投稿します。 Swiftでフォーマットを構文解析するためのパーサーよりも興味深いトリックがあります。 しかし、突然誰かが見たいと思うでしょう： http : //github.com/bealex/KTV



おそらく、私は多くのことを逃したか、考慮しませんでした。 たぶん誰かが同様の経験を持っていますか？ コメント、またはメール：alex@jdnevnik.comに書いてください。