Make approach to defining enums consistent across the project

オープン
#663 コメント 6 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 6 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
go
領域
tooling

調査の方向性

#654 で Ecosystem に導入された enum 定義を analysis.Mode、staticanalysis.Task、analysisrun.DynamicPhase と比較する。それぞれが文字列、リスト、フラグ、JSON シリアライゼーション、String() をどのように扱っているかを確認し、数値ベースと文字列ベースの違い、および必要な marshaling 動作を網羅する、単一の文書化されたアプローチについて合意する。

索引モデルが issue の本文から書いたものです。

説明

go internal cleanup needs discussion

#654 introduces the enum type Ecosystem implemented differently to other enums (e.g. analysis.Mode and staticanalysis.Task and analysisrun.DynamicPhase)

We should develop a consistent approach to how we define enums:

Some areas that should be covered:

  • should the base type be string vs numeric
  • how do we handle lists of enums
  • how do enums interact with flags
  • how do enums handle serialization (JSON)

Both:

  • require String()

Numeric based enums:

  • can use iota
  • can consume as little as 8bits (byte)
  • very fast to compare equality
  • encoding.TextMarshaler and encoding.TextUnmarshaler needed to support flag.TextVar and json serialization
  • requires strings to be specified for marshaling and unmarshaling (although an array of strings may make this easier)

String based enums:

  • consume 128 bits per enum
  • simpler String() function and serialization
  • equality is more costly (at minimum two comparisons, maximum the size of the shortest string)
主要言語
Go
スター
925
フォーク
75
平均マージ
4日 2時間
マージ済み PR(30日)
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ossf/package-analysis のほかの issue

ossf/package-analysis の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。