Godot: GDScriptの注釈

カスタムアノテーションを正しく理解しているので、次のようなものがあります。

<strong i="6">@description</strong> "Adds two numbers and returns the result."
<strong i="7">@parameter</strong> name=num1 type=float description="The first number"
<strong i="8">@parameter</strong> name=num2 type=float description="The second number"
<strong i="9">@returns</strong> type=float description="num1 and num2 added together"
func add(num1, num2):
    return num1 + num2

そして、これらのアノテーションを返す関数、たとえばget_annotations("add")呼び出すことができますか？ これらのアノテーションがGodotによって組み込みのキーワード/アノテーションとして認識されない場合でも、

@ LikeLakers2はい、それがその要点です。

私はそれが好きです、私は背後にある実装については知りませんが、GDscriptコードではそれは現在のように見えるよりもずっときれいに見えるでしょう。 特にsetgetの例では。

これは非常に便利ですが、読みやすくするために1行のステートメントを許可する必要があります。 例えば、
<strong i="6">@onready</strong> var a = $Aを許可する必要があります。 そうでなければ、これは大量の改行を追加し、この場合、onreadyの有用性を無駄にします。

何かのようなもの

<strong i="10">@onready</strong>
    var a = $A
    var b = $B
    var c = $C

同じ注釈を複数のステートメントに適用すると便利です。

また、コロンを使用して、注釈が終了する場所と影響を受けるステートメントが開始する場所を示し、GDScriptの残りの部分と一致させることができます。

注釈を明確な開始と終了で解析できる場合は、セミコロンは不要であり、必要に応じて同じ行に配置できます（たとえば、「（）」を使用する場合、または引数がない場合）。

vnenは古いショートカットキーワードを削除するつもりはないと思いますか？

また、蛍光ペンでこれらを処理することも役立ちます。

ここでのパーティーに遅れましたが、これがエクスポート変数のカテゴリを提供し、ツール/デバッグスクリプトの分割を作成する方法に非常に興味がありますか？

暫定的に3.2ロードマップを作成しますが、エディターに使いやすさの向上を提供するために、これが遅かれ早かれ実装されることを本当に望んでいます。

####不評な意見が寄せられています：

gdscriptの構文が大幅に変更されているのはなぜですか？ もともとは、シンプルで、習得しやすく、直感的になるように設計されていました。 これらすべての新しい追加（入力されたgds、注釈）により、新しい開発者にとって非常に混乱することになるのではないかと心配しています。 たとえば、godotの新しい人がチュートリアルを見て、LikeLakers2の投稿にあるコードを見るとしたら、頭が爆発するだろうと思います。 どちらかといえば、彼らはそれについて/それがどのように機能するかなどについてたくさんの質問をしなければならないでしょう。

みんなのgdsへの愛情や、貢献者がどのようにそれを改善したいのかなどを完全に理解しています。実際のゲーム開発者と貢献者の間に断絶があるかもしれないと感じています（貢献者がゲーム開発者ではないと言っているのではなく、機能は実際には必要ありません）。 誰もがこれらの機能を利用する必要はありません。 gdsがその単純さからどんどん離れていくのではないかと心配しています。それだけです。 それは既に十二分です...

また、exportキーワードに3行を指定することは、すべてを1行で指定する場合に比べて非常に面倒です。 例： onready var my_sprite = $Spriteははるかにクリーンです（とにかく私にとって）

ポイント4に関しては、これはエディターAFAIKで実行できます。 また、imoは、「特定の警告を無効にする」ためにコードのいたるところに注釈を付けると、非常に厄介なコードになる可能性があります。

gdscriptの構文が大幅に変更されているのはなぜですか？ もともとは、シンプルで、習得しやすく、直感的になるように設計されていました。 これらすべての新しい追加（入力されたgds、注釈）により、新しい開発者にとって非常に混乱することになるのではないかと心配しています。

ほとんどの（すべてではないにしても）GDScript構文の変更は、古いコードと互換性があります。 主な目標は、GDScriptを使用する開発者の生産性を向上させることです。例：

• matchステートメントは、switch-caseステートメント（非常に要求された）を可能にし、人々が配列と辞書を簡単に照合できるようにすることで、それをさらに改善します。
• onready変数（2.xで新しく追加された）は、頻繁に使用されるパターンを具体化します。つまり、 _ready変数を初期化します。
• 型付きGDScriptを使用すると、開発者は、間違った型のエラーが発生しないことを最終的に知ることができ、同時により良いオートコンプリートの恩恵を受けることができます。 これはオプションであるため、初心者は最初のゲームでそれを学ぶ必要はありません。

実際のゲーム開発者と貢献者の間に断絶があるかもしれないと感じています。

これはオープンコミュニティです。 ゲーム開発者は、あなたと同じように、来て意見を表明することを歓迎します。 いずれにせよ、アノテーションが現実になるまでにはかなりの時間がかかります。

[...] gdsがその単純さからどんどん離れていくのではないかと心配しています。それだけです。 すでに十分すぎるほどです...

すでに十分に良ければ、機能リクエストを受け取ることはできません。

また、exportキーワードに3行を指定することは、すべてを1行で指定する場合に比べて非常に面倒です。 例：onready var my_sprite = $ Spriteははるかにクリーンです

構文はまだ完成していません。 onreadyおよびexportキーワードがすぐに置き換えられない可能性があります。

私はこのアイデアが本当に好きで、C＃の属性がとても好きです。

クラスとシグナルのアノテーションも興味深いかもしれません。

プロパティ、メソッド、またはクラスに特定のカスタムアノテーションがあるかどうかに関係なく、自動的に動作するインスペクタープラグインは簡単です。
構文に関しては、オプションで1行に記述できるものを好みますが、それほど重要ではありません。

カスタムアノテーションを定義するプロセスはどのようになりますか？ コード内で毎回自由に定義されるのではなく、クラスと同じように、ユーザーが一義的な定義で作成することをお勧めします。

これにはもっと調査が必要だと思います。完全な初心者が飛び込もうとしていることを混乱させないように、言語に（オプションの構文などとして）追加するのは素晴らしいことだと思います。

次の構文を見ても大丈夫だと思います。

<strong i="7">@export</strong> type=String, hint=MULTILINE

「パラメータ」の間にコンマを追加すると、次のように現在の構文との整合性が少し向上すると思います。

export (String, MULTILINE) var my_var

最初のバージョンはもう少し冗長ですが、それはまたそれをより明確にし、オートコンプリートを使用すればそれほど害はないはずです:)

今後、構文に関する議論がさらに増えるはずです。 全体的に私はその考えが好きです。

アノテーションは、構成を挿入するための良い方法です。 ただし、構成とコードを分離する方が、IMOのよりクリーンなアプローチになる可能性があります。 ヘッダーファイルがより役立つようにそれらを追加している可能性があります。

@ bojidar-bgのコメントから...

いずれにせよ、アノテーションが現実になるまでにはかなりの時間がかかります。

誰かがこの実装を遅らせる「ブロッキング」の問題が何であるかを説明できますか？ GDScript / manpowerに精通しているだけですか、それともアノテーションをサポートするために事前に実装する必要がある特定の機能がありますか？

さて、私のコメントからかなりの時間が経過したので、それはすでにそれを証明していると思いますか？

アノテーションサポートの主なブロッカーは、コア開発者に構文とセマンティクスについて合意させることです。 その後、実装は比較的簡単になるはずです。

アノテーションはメタデータ専用であり、スクリプトやエディターの動作に影響を与えないことを望んでいるため、 @ reduzとこれについて話し合う必要があります。 これは私の最初の提案を全く無意味にするでしょう。

特に単一のキーワード（ onready 、 master 、 puppetなど）を置き換える場合は、注釈が十分に明確であると思います。 しかし、それでもコンセンサスに達する必要があります。

説明したように、これはGDScriptへの素晴らしい追加になると思います。 メタデータに限定すべきではないと思います。変数に使用されるキーワードの多く、特に場合によっては少し読みづらくなる可能性のあるexportを確実に追い抜く必要があります。 それを複数のステートメントに分割することは、理解に役立つと思います。

また、その3年前の問題＃6204をエレガントな方法で解決するためにも使用できます。

<strong i="8">@export</strong>
<strong i="9">@export_tooltip</strong> "The name used when displaying this item in the inventory and in shops."
var display_name := ""

また、メタデータ以上のものをサポートする必要があることにも同意します。 これにより、多くのロジックが簡素化され、読みやすさが向上します。

@willnationsdevに同意し、アノテーションを使用してコードでシグナルを接続したいと思います。このようなものは、コードの可読性を本当に向上させることができます。

@connect("timeout")
func _on_Timer_timeout():
   ...

@rludersは、スクリプトがTimerノード上にあると想定しています。

もちろん@Zylann 。 簡単な例です。 「ターゲット」パラメータをサポートし、自己接続のために省略できます。 たとえば、スクリプトがTimer外部で実行されている場合：

@connect("timeout", $Timer)
func _on_Timer_timeout():
  ...

これをどのように実装できるかわかりませんが、特にキーワードについては、gdsで注釈を確認したいと思っています。 また、記録としては、注釈を区切るためにセミコロンや改行の代わりに「（）」を使用することをお勧めします。

独自の注釈+本格的な注釈プロセッサを作成できればさらに良いでしょう。

もちろん@Zylann 。 簡単な例です。 「ターゲット」パラメータをサポートし、自己接続のために省略できます。 たとえば、スクリプトがTimer外部で実行されている場合：

@connect("timeout", $Timer)
func _on_Timer_timeout():
  ...

それは何らかの方法でプラグインによってサポートされる可能性があります、私はそれをコア機能にしません。
プラグインはさらに強力になる可能性があります。

私が言えるのは、これらのものが実装される前にgdscriptを学んだことをうれしく思うということだけです。

@export_hint(ENUM)
@export_hint_string("Attack,Defense")
export var my_enum : int = 0

初心者として、私にとっては非常に困難で解析が困難だったでしょう

@sleepcircleすべての場合においてGDScriptをシンプルに保つように努めます。 したがって、ここで皮肉を言う必要はありません。引用したコードは単なる提案であり、将来の構文ではありません。

すみません、皮肉を言うつもりはありませんでした。 大多数がこれらの追加を承認しているように見えたので、私はちょうどそれらが避けられないと思っていました。

ゲーム開発インストラクターとして$ 0.02を投げたかっただけです。 警告：あまり貢献しない不必要に長いコメント。新しい開発者がこれをどのように認識するかについて、プログラミングを5年間教えた私の経験だけです。

注釈のような新しい言語イディオムを考え出すときは、できる限りのアフォーダンスを便乗させることが重要だと思います。 たとえば、 connect場合、新しい開発者にとって、パラメーターを取り込んでいくつかの副作用がある関数を機能する

@がメタデータ専用に使用された場合、新しい開発者が@を見ると、コードロジックに影響を与えないメタデータとして認識します。 ロジックに影響を与える場合は、 xとして使用されることもあれば、 yとして使用されることもある新しいイディオムを追加しないことが重要です。

現在、変数を変更するには、varの接頭辞、接尾辞、および代替があります。 必ずしも「変数修飾子」ではないものをいくつかリストしますが、新しい開発者はそれらをこのように見る可能性があります

• プレフィックス： onready 、 export(...)
  
  
  
  • これらはそれぞれ異なるタイプの動作をします。 onreadyは実行時変数のロードに影響します。 exportは一種のエディターヒント/メタデータです。 それらを同じ場所で使用することは、実際にはそうではないのに、彼らの行動は何らかの形で関連しているべきだと感じます
  
  
• 代替案： class_name 、 extends 、 signal 、 enum 、 const 、 func
  
  
  
  • これらの代替形式は問題ないように感じますが、「enum」と「const」を、たとえばintやstringsと区別するのは奇妙な選択のようです。
  
  
• サフィックス： setget
  
  
  
  • 独自のカテゴリのSetgetは問題ありませんが、開発者にとっては砂糖のキーワードであり、論理シフトはそれほど多くないという点でexportに似ています。 ここでは意見の違う人がいますが
  
  
• 中間のどこか： var x : int = 5入力する
  
  
  
  • 特に「enum」と「const」が同じことを表すvarの代替キーワードである場合、この中間の入力は奇妙に感じます。 constは、ゲームロジック自体のツールよりも開発者のエクスペリエンスを変更するという点で、setgetに似ているという議論は間違いありません。
  
  

それでは、注釈の追加を見てみましょう。

注釈は、新しい開発者に教える必要があるまったく新しい概念/イディオムになります。 理想的には、新しい開発者は、新しいイディオムが役立つようになったときに有機的に拾い上げることができるように、

• （Tier 1）func、var、および関数呼び出し、条件、ループなどのいくつかの基本的なプログラミング概念のみを知っているゲームを作成できます。
• （Tier 2）次に、シグナル、定数、列挙型などの有用な糖/機能を学習します。
• （Tier 3）彼らはsetgetのようなショートカットをonreadyで学びます
• （Tier 3.1）彼らは開発者専用の砂糖を学びます。それはゲームを変えることはありませんが、エクスポート、エディターの説明、ツール、タイピングなどでプロセスを変えます。
• （Tier 4）純粋なドキュメントとプロジェクト構造

Tier3-4がアノテーションの主要なターゲットであるように感じます。 2つの異なる実装のために生徒に与える2つのエレベーターピッチがあります。

• 純粋なメタデータ：「ドキュメントとコラボレーションを支援するために、スクリプトにメタデータを追加するための注釈について学びます。コメントを使用するよりも強力です。」
• Devの速記/砂糖：「コードを減らしたり、読みやすくしたりする場合は、注釈を参照してください。注釈を使用すると、いくつかのエディターツールとショートカットを提供しながら、変数と関数を説明できます。」

私は多くの開発者にGodotを教えてきましたが、注釈を付けるには少なくともTier 3オプション、多くてもTier 4を使用すると思います。注釈が表示されるまで、 @記号を表示する必要はありません。全体的でかなり複雑なゲームを構築し、そのプロセスを改善しようとしてい

つまり、「ドキュメントが必要な大規模なプロジェクトを構築したらアノテーションを学ぶ」と人々に伝えるのは簡単なので、ゲームの機能にとって重要ではない/代替の実装がある、または純粋にドキュメント用の開発略記専用のアノテーションを使用することに私の意見があります。

スレッドからの特定のポイント：

• エクスポートはどのゲームにとっても重要ではないため、エクスポートには問題ないはずです。
• Onreadyは早い段階で便利なショートカットですが、新しい開発者は_readyで開始することから始めることができ、ネストされたアノテーションの可能性はonready書く回数がはるかに少ないことを意味するため、必要ありません。
• setgetはすでにそのような奇妙な構文であり、唯一の接尾辞としてすでに独自のイディオムであるため、完全にそこに含まれている可能性があります
• 接続：私が先導しているように、それは関数呼び出しイディオムですでに完璧です。 接続する方法が複数あると、チュートリアル/サンプルコードスペースが混乱する可能性があります。 おそらく、人々が独自の注釈を書くことを許可することは、これを標準化するよりも優れているでしょう。そうすれば、閉じたプロジェクトに取り組んでいる開発者は、必ずしもパブリックスペースを混乱させることのない注釈のライブラリを構築できます。
• タイプ：タイプは現在奇妙な場所にあり、一部のタイプ修飾子は代替であり、一部のタイプ修飾子はその中間にあります。 おそらくそれらを注釈として持つことは機能します： @type(const int) @type(enum) 、これはそれらすべてを開発者指向の砂糖として統合します

繰り返しになりますが、大きな貢献ではありませんが、注釈の下でどの機能を包括する必要があるかを考えるときの考えです。 それらは素晴らしいアイデアだと思いますが、どこに収まるのか正確にはわかりません。長さについて申し訳ありませんが、私はいつも少し冗長すぎます。

私はこれが嫌いです。
すべてのフィールド、プロパティ、メソッドに大量のアノテーションを付けたくありません

もっとキーワードが欲しい

大量のキーワードが気に入らない場合は、一部を削除できます

export MyClass : Node2D # export replaces class_name, : replaces extends 

signal mySignal #signal is kept

group(MyHeader, "res://icon.png" )
export var my_property : Array(int) setget _set_my_property, _get_my_property # : replaces export type

var test = 0 # no need for onready. variables declared outside of _ready automatically try to be onready vars

#others are kept

私は元の提案に完全に同意します。

私は上記のコメントに同意しませんが、長所は短所を大幅に上回っています。

@ Shadowblitz16これらの提案の多くは、次の理由で、ここの人々を混乱させています...

export MyClass : Node2D # export replaces class_name, : replaces extends

export 、 class_name 、 : 、およびextendsそれぞれ4つの完全に別個のデータポイントとシステムを構成します。 他のものに回復不能な影響を与えることなく、単にそれらを切り替えることはできません。

• exportは、エディターGUIを構築するためにインスペクターに送信される生成されたPropertyInfoオブジェクトを構成します。
• class_nameは、スクリプトをグローバルクラスとしてScriptServerに登録します。 技術的には型システムとは何の関係もありません。 これは、実行時ではなく解析時にスクリプトのグローバルインスタンスを作成する場合に限り、GDScriptの「静的型付け」の一部です。
• :は、オプションの型ヒントに使用され
• extendsは、継承されたクラスに使用されます（ご存知のとおり）。 これは他の言語ではかなり一般的な構文であり、すべてのドキュメントとチュートリアルはすでにこの方法に従っています。 これから離れて、純粋に表面的な理由でより多くの作品を作成する強いインセンティブはありません。

group(MyHeader, "res://icon.png")

これが何をするのか私にはわかりません。 つまり、ノードは「MyHeader」グループに追加されるようです（これは理にかなっている可能性があります）が、アイコンは何ですか？ グループにはアイコンが関連付けられていません。

export var my_property : Array(int) setget _set_my_property, _get_my_property # : replaces export type

前に述べたように、これらはすべて、同じシステムではなく、異なるシステムに影響を及ぼします。 さらに、値のタイプまたはその初期化を柔軟にしたい場合があります。 たとえば、動的GDScriptでは、次のようなことができます。

onready export(NodePath) var the_node = get_node(the_node)

var test = 0 # no need for onready. variables declared outside of _ready automatically try to be onready vars

準備完了通知の前にデータを初期化しても意味がありません。 スクリプトは、Nodeクラスではなく、Objectクラスに関連付けられています。 スクリプトのプロパティは、構築中に初期化されます。 Nodeクラスのコンストラクターに到達しても、それは変わりません。 _ready()通知は、インスタンス化のかなり後に発生します。 変数の初期化のデフォルトのタイミングがオブジェクトとノード間で異なると、非常に混乱し、Godotを学習して使用する人にとっては多くの予測できない動作につながります。

私はあなたの提案を打ち切るつもりはありませんが、むしろ人々がこれらの提案された変更の正当性を見ていない理由を説明するだけです。

@willnationsdevその大丈夫私は理解しています
注釈と追加のキーワードの両方を行うのはどうですか
このようにして、ユーザーは必要に応じて注釈を使用でき、フィールドごとに数十の注釈を付けたくない場合はキーワードを使用できます。

編集：C＃を、そのように組み合わせることができる属性として注意してください。
[Attribute1(), Attribute2()]
ただし、これは行数を減らすのに役立つかもしれませんが、それでも少し醜いです

@ Shadowblitz16可能であれば、物事を行うための明白な方法を1つだけにしたい。 2つの異なる構文を持つことは、その目標に反します。

@Calinou人々が妥協できないのであれば、gdscriptはそのままにしておくべきだと思います。
1-下位互換性を不必要に壊します
2-それはより大きなファイルと読みにくいコードを作成します
3-それは人々に彼らが慣れていない新しいシステムへの変更を強制します。
4-それは人々に彼らが望まないかもしれないシステムを使用することを強制します

1-下位互換性を不必要に壊します
2-それはより大きなファイルと読みにくいコードを作成します
3-それは人々に彼らが慣れていない新しいシステムへの変更を強制します。
4-それは人々に彼らが望まないかもしれないシステムを使用することを強制します

正直なところ、それらはかなり悪い議論です。 これらの4つのポイントのうち3つは、APIの大きな変更に固有のものであり、最初のポイントは、古いキーワードベースのシステムとの互換性をしばらく維持することで回避できます（非推奨の警告がある可能性があります）。

_編集：私が推測する自動変換ツールを提供することもできます。_

ポイント2については、アノテーションがより多くの行を含むファイルにつながる可能性があるという事実に誰もが同意すると思いますが、ここのほとんどの人は、それが読みにくいコードを作成するという事実に同意しません。

@groudこれは不要なものにアノテーションを使用しています
1-機能するものを非推奨にする必要があるのはなぜですか？
2-フィールドを表示するために5行下にスクロールする必要がある場合は読みにくくなります

• エクスポートは基本的に編集者への公開キーワードです
• onreadyは基本的に、スクリプトが実行される前のvar宣言です。

どちらも注釈には適していません

メンバー定義は、これが良いことを私が本当に見ることができる唯一のものであり、この場合、それらは折りたたむ必要があります。

@groudこれは不要なものにアノテーションを使用しています

このスレッドでは、多くのユースケースが提示されています。 ドキュメント、イントロスペクション、より複雑なプラグインなど、キーワードでカバーできないアノテーションのユースケースはたくさんあります。

1-機能するものを非推奨にする必要があるのはなぜですか？

そのようなことをする理由はたくさんあります。 よりクリーンなAPIや柔軟性などを実現するために、機能を進化させる必要があるかもしれません。新しいバージョンが広く使用されたら、可能な場合は以前のバージョンとの互換性を削除することをお勧めします。これには間違いなくメンテナンスコストがかかるためです。

2-フィールドを表示するために5行下にスクロールする必要がある場合は読みにくくなります

誇張する必要はありません。 そのような提案を議論する目的は、そのような問題を回避するのに十分スマートな構文を可能にすることです。 私見ですが、エクスポートのヒントは、エクスポートの注釈への引数として統合できます（名前付きの引数システムがあれば）。 このような状況では、システムは以前よりもさらに少ないスペースで済みます。

また、フィールドと同じ行に注釈があることも想像できます。 これで問題が発生することはないと思います。

エクスポートは基本的に編集者への公開キーワードです
onreadyは基本的に、スクリプトが実行される前のvar宣言です。
どちらも注釈には適していません

さて、あなたはおそらく注釈が何のためにあるのかについて先入観を持っているでしょう。 これらのユースケースは注釈システムに完全に適合していると思います（そして多くの人がそうしているように見えます）。 しかし、確かに、私はそれぞれの状況がケースバイケースで議論されるべきだと思います。

「線」の議論が特に良いとは思わない。 注釈で1行に複数のステートメント（または「プレフィックス」フォーム）を直接許可しない場合でも、区切り文字として;を使用できます。

<strong i="7">@onready</strong> var my_sprite = $Sprite
@onready; var my_sprite = $Sprite


@export_hint_string("Attack,Defense")
@export_hint(ENUM) export var my_enum : int = 0

@export_hint_string("Attack,Defense")
@export_hint(ENUM); export var my_enum : int = 0


<strong i="8">@export_hint_string</strong> "Attack,Defense";
<strong i="9">@export_hint</strong> ENUM export var my_enum : int = 0

<strong i="10">@export_hint_string</strong> "Attack,Defense"
<strong i="11">@export_hint</strong> ENUM; export var my_enum : int = 0


<strong i="12">@export</strong> type=String hint=MULTILINE; var my_text = ""

# more options

@export(type = String, hint = MULTILINE) var my_text = ""
@export(type = String, hint = MULTILINE); var my_text = ""

@export(String, hint = MULTILINE) var my_text = ""

# I personally prefer this one (positional and named args supported, default/optional args too)
@export(String, MULTILINE) var my_text = ""
@export(String, hint = MULTILINE) var my_text = ""
@export(type = String, hint = MULTILINE) var my_text = ""
@export(int, ENUM, "Attack,Defense") var my_enum:= 0

編集：ああ、私は遅すぎました、 @ groudはすでに行の議論に取り組んでいます。 まあ、少なくともそれらのいくつかのコード例は、このスレッドに何かを追加しました。

それはあなたたちの意見です。
個人的には@は醜いと思います

編集：
では、メンバー宣言はどのように機能しますか？
そうすることは恐ろしいでしょう

<strong i="10">@description</strong> "Adds two numbers and returns the result."
<strong i="11">@parameter</strong> name=num1 type=float description="The first number"
<strong i="12">@parameter</strong> name=num2 type=float description="The second number"
<strong i="13">@returns</strong> type=float description="num1 and num2 added together"
func add(num1, num2):
    return num1 + num2

@descriptionの最初からfuncの最初まで折りたたむことができなかった場合を除きます

アノテーションはタイプを置き換えることを意図したものではないと思います（あなたの例のように）。 ドキュメントの注釈が必要ない場合は、それらを使用する必要はありません。

func add(num1: float, num2: float) -> float: return num1 + num2

この混乱は、私が知る限り、実際の型を使用できないエクスポートヒントの理想的とは言えない状況に起因している可能性があります（そして、驚くべきことに、配列などの一部の型のサポートを驚くほどエクスポートするジェネリック型がないという問題）。

個人的には@は醜いと思います
では、メンバー宣言はどのように機能しますか？
そうすることは恐ろしいでしょう

他の言語では、この目的は通常、注釈ではなくコメントを提供し、通常、提案されたものと同等かそれ以上に冗長です。 C言語ファミリー（最も人気のある言語）では、 @はアノテーションにかなり一般的です（たとえば、Java、JavaScript、TypeScript、Scala、そして私がPythonを読んだものからも）。

TypeScript（ドキュメントの型は必須ではなく、ツールは実際の型を使用できると思います）：

/** Adds two numbers and returns the result.
 * <strong i="16">@param</strong> num1 {float} The first number
 * <strong i="17">@param</strong> num2 {float} The second number
 * <strong i="18">@return</strong> {float} num1 and num2 added together
  **/
const add = (num1: number, num2: number): number => num1 + num2;

ファンクのような味：

@description("Adds two numbers and returns the result.")
@parameter(num1, "The first number", type=float)
@parameter(num2, "The second number", type=float)
@returns("num1 and num2 added together", type=float)
func add(num1: float, num2: float) -> float:
    return num1 + num2

重複タイプなし：

@description("Adds two numbers and returns the result.")
@parameter(num1, "The first number")
@parameter(num2, "The second number")
@returns("num1 and num2 added together")
func add(num1: float, num2: float) -> float:
    return num1 + num2

パレンレスフレーバー：

<strong i="28">@description</strong> "Adds two numbers and returns the result."
<strong i="29">@parameter</strong> num1 "The first number"
<strong i="30">@parameter</strong> num2 "The second number"
<strong i="31">@returns</strong> "num1 and num2 added together"
func add(num1: float, num2: float) -> float:
    return num1 + num2

私はこの構文がドキュメントコメントに最適です。 ドキュメント以外のアノテーションにはfuncのような構文を使用したいので、ドキュメント化の目的でアノテーションを使用することについてはまだ確信が持てません。

前の例の注釈名を使用しました。 @parameterは他の言語と同じように単純に@param 、 @descriptionは@desc 、 @descrまたは@func 。

GodoDocでは、TypeScript（それ自体はJSDocとJavadocに基づくTypeDoc）に基づく構文を使用していますが、私の意見では、非常にうまく機能しているようです。

## Same as [[bool_]], but `on_false`/`on_true` are functions.
## Only selected function will be called and its return value will be returned from `bool_lazy`.
## <strong i="44">@typeparam</strong> T {any} Return type
## <strong i="45">@param</strong> cond {bool} Condition
## <strong i="46">@param</strong> on_false {FuncLike<T>} Function to call and return its result when `cond` is `false`
## <strong i="47">@param</strong> on_true {FuncLike<T>} Function to call and return its result when `cond` is `true`
## <strong i="48">@return</strong> {T}
func bool_lazy_(cond: bool, on_false, on_true): return GGI.bool_lazy_(cond, on_false, on_true)
var bool_lazy = funcref(self, "bool_lazy_")

@descriptionの先頭からfuncの先頭まで

はい、一般的に折り畳みとデフォルトの折り畳みのオプションはエディターへの素晴らしい追加です（たとえば、内部クラスがデフォルトで折りたたまれる設定で有効にできるなど、ブロックのタイプに基づいて折り畳みます）。

注釈を前または上に配置する機能が好きです。このため、 @annotation(a, b)は便利で、パラメータが指定されていない場合は角かっこはオプションです。 exportとonreadyがプロパティで非常に一般的であることを考えると、前に置くことができるので、今日のキーワードと同じ速度で書くことができます。

ただし、使用法に関しては、ドキュメントも嫌いです。 私はプログラムに影響を与える注釈に慣れていますが（間接的であっても）、ドキュメントはコメントのように使用するためにその量を3倍にすることが多く、その後どこにでも表示され、機能的な注釈と同じように強調表示されます...それは何かに適合しませんそのユビキタス。 基本的に、私はC＃で見られるのと同じ注釈の使用法が好きです。これにより、メンバーの上に注釈を書き込む必要がはるかに少なくなります（通常、注釈は非常にまれであり、いくつかの例が示すように、全員が5行を書き込む必要はありません）。 。 議論がスクリプトドキュメントを指定するためのAPIを持たないGodotに関するものである場合、それは問題であり、注釈IMOだけで解決することはできません。 少なくとも、それをオプションで使用できると思いますが、このように強制されたくはありません。これは、本格的なドキュメントには不便です。 （さらに、スクリプトはGDScriptだけではなく、 _get_property_listを使用するエッジケースはこれをさらに厄介にします）

私はあなたのZylannに完全に同意すると思います。 私は個人的に、キーワードのようなエクスポート（またはオンレディ）のためにそのような構文を許可します：

# No parenthesis when there are no parameters
<strong i="6">@export</strong> var myvar
# With parenthesis for parameters
@export(ENUM, "Up,Down,Left,Right") var myvar2
# Being able to write the annoation on the line before
@export(ENUM, "Up,Down,Left,Right") 
var myvar2

ドキュメントの部分に関しては、構文をさらに単純化します（ @mnnの例を

<strong i="11">@description</strong> "Adds two numbers and returns the result."
<strong i="12">@parameter</strong> "The first number" # No need to name the args if they are ordered
<strong i="13">@parameter</strong> "The second number"
<strong i="14">@returns</strong> "num1 and num2 added together"
func add(num1: float, num2: float) -> float:
    return num1 + num2

ただし、ドキュメントを他の場所に書き込むことができるように、別のシステムを開発することが必須であることに同意します。 jsonでは、XMLまたは最初のファイルと言います。 コード内のドキュメントはすべてのプロジェクトに適合するわけではありません。ドキュメントのためだけに多くの注釈を追加すると、煩わしくなり、場合によってはコードが読みにくくなる可能性があることに同意します。

関連性のためのリンク：godotengine / godot-proposals＃177

パーティーにはかなり遅れましたが、プラグインの開発にメタデータとリフレクションに大きく依存している開発者として、アノテーションがgodotのものになることを本当に望んでいます。

いくつかのもの（エクスポートやオンレディのものなど）がより美しくなると思いますが、私の主な議論は、注釈を最大限に活用できるカスタムプラグインについてです。

onreadyキーワードとその制限について。

ほとんどの人は、ノード参照を早い段階で初期化するためにonreadyを使用していると言っても過言ではありません。 _ready依存するいくつかのシーンをインスタンス化すると、 null参照の問題に遭遇する可能性があるため、長期的には問題がなければ実現できない可能性があることを除いて：

func explode():
    var bomb = preload("res://explosion.tscn").instance()
    # Oops, forgot to `add_child(bomb)` earlier
    bomb.fuse.wait_time = 5.0 # ERROR: fuse is `null`
    add_child(bomb)
    # ... because `fuse` is a $Timer node 
    # which is only initialized once added to the scene tree.

もちろん、 fuseを設定する前に、インスタンス化されたシーンをadd_child()する必要がありますが、シーンがシーンツリーに追加される前に、他のノード/オブジェクトが正確なヒューズを認識する必要がある場合はどうでしょうか。 ？

しばらくして、 https： //github.com/godotengine/godot/issues/33620#issuecomment-559999681で説明されている解決策を見つけました。 お気づきかもしれませんが、 onreadyはNOTIFICATION_READY 、実際に必要なのはNOTIFICATION_INSTANCEDで、参照をさらに早く初期化します。 唯一の問題は、 oninstancedキーワードがないことです。そして、私が何につながっているのか理解できると思います。 🙂

したがって、スクリプト言語を肥大化させることなく、 @oninstanced機能を備えた他のいくつかのコーナーケース（いつものように！）もサポートしながら、 onreadyキーワードを注釈として実際に作り直すのは良いことだと思います、および初期化に関連する他の通知のサポートを追加します（ _init 、 _enter_treeなど）。

関連する提案：godotengine / godot-proposals＃260。

より具体的な詳細を含む提案を開きました： https ：

上記の提案に取って代わられました。