Godot: GDScriptでのオプションの入力

あなたができるように見えます

func myfunction(something = InputEvent):

何も渡さない場合は空の入力イベントが発生しますが、変数がそのタイプになるように強制することはありません

myfunction('string')

うまくいくでしょう。

ロードマップ上にあります:)
https://github.com/godotengine/roadmap/blob/master/ROADMAP.md

@Hinsbart
それがどのように見えるか、またはGDScriptの他の部分でどのように機能するかについての参照はありますか？ それとも、ロードマップ上の単なるアイデアですか？

残念ながら、いや、いくつかのircの議論を除いて、まだそれについての参照はありません。

CC @reduz 、彼がこれについて何を考えているかについてのいくつかのヒントを与えるために。

@ LeonardMeagher2は、あなたが書いたもののように見えるはずです

どうですか：

func myfunction(something is InputEvent, something_else is String):

それは私にとってかなり良いことであり、isキーワードがより便利になり、コードが理解しやすくなります

同意しません。 String somethingまたはsomething : Stringどちらでも大丈夫です。 something is Stringは私には悪いようです。

String somethingまたはsomething is Stringどちらも問題ありません。 コロンを使用すると、コード内に多くのコロン記号が作成されると思います。

isが使用されない場合、私は他の言語からのこの表記法に慣れており、より一般的だと思うので、 String somethingを好みます。

@neikeq
var something:String = " "ように、変数を作成するときにタイプを宣言できれば、同意します

そうでなければ、関数定義だけでセミコロンを使用する方が混乱するだろうと思います。

「Is」は現在gdscriptの継承について尋ねるために使用されていますが、なぜそれを要求できなかったのでしょうか。

CのようなタイプのプレフィックスはIMOの方が優れています。 これは短く、入力が速く、型を使用するときにvarまたはfuncを置き換えることができます。

例：

int some_variable

int some_function(int some_argument):
    return some_variable + some_argument

それに対する私の投票。

@ juan-garcia-m
タイピングのようにcに慣れていない人にとっては理解しやすいとは思いません。 入力する方が簡単かもしれませんが、読みにくくなると思います。
関数または変数とは何かを一目で知ることを好みます。これらのキーワードを型に置き換えると、その機能が削除されます。 これが、CとC ++が入りにくい理由の1つです。

言うまでもなく、私のために言語を作ることはできませんが、私だけがこのように感じているわけではないと確信しています。

「is」の問題の1つは、現在3.0で、以前は「extends」であったもの、つまりノードがクラスに属しているかどうかを確認するために使用されていることです。

@ Zireael07
そのため、関数宣言で型をチェックするのが適切だと思います。
スクリプトの先頭では引き続きExtendsが使用されますが、型チェックには「is」が使用されます（リテラルの場合はtypeofだと思います）。

Cスタイルのプレフィックスは一般にもっと複雑であり、これらのタイプの言語の場合、標準は変数：タイプの規則であるように思われるため、これが使用されます。

なぜこれが閉鎖されたのですか？ それはまだ実装されていません...

ただの話し合いだったので閉じましたが、再開して目的の機能の進捗状況を追跡します

Cスタイルのプレフィックスが再考されることを本当に望んでいます。 Typescriptでの経験から、変数を初期化するときの生産性が低下し、個人的にはコードが読みにくくなると感じています。 これを書かなければならない...

var foo: String = 'bar'

... varキーワードをタイプに置き換えるだけでなく...

String foo = 'bar'

...私を狂わせます。 これは非常に小さくてつまらないように聞こえますが、ゲームでの長期的な作業では、必要以上のキーストロークが発生します。

外観は次のとおりです。

Python構文に従います（TypeScriptやHaxeにも似ています）。

これはかなり意見が分かれています。 たとえば、私はたくさんのTypeScriptコードを書き、構文が本当に好きです。 タブとスペースのように、誰もが何が最善かについて独自の意見を持ち、通常は背景に関連しています。 Stringを見て、それが関数なのか変数なのかわからないよりも、 varを見て、それが変数であることを知っている方が簡単だと思います。 「タイプするのが速い」というのは良い議論ではないと思います。「間違いを犯しにくい」と「読みやすい」の方がはるかに優れています（ただし、まだ意見があります）。

Pythonの方法のもう1つのポイントは、解析がはるかに簡単なことです。 現在のパーサーは、これに対応するために大幅に変更する必要はありません。 接頭辞付きのタイプの場合、何をするかを決定するために、コンテキストについてさらに多くのことを考慮する必要があります。

ええ、コードの可読性は非常に主観的です。 Cスタイルの構文でどのように見えるかを例に書き直しました。 _I_以下のコードが読みやすく、変数と関数を区別するのに問題はありません。

extends Node

const int MY_CONSTANT = 0
String my_member_variable = "Value"

void my_empty_func():
    pass

float my_other_func(bool arg1, Node2D arg2, bool default = false):
    Vector2 local_variable
    int other_variable = 0

    return float(other_variable)

「入力が速い」というのは、開発者の生産性に直接影響するため、良い議論ではないことに同意する必要があります。 Pythonスタイルは、Cのスタイルよりも読み取りと書き込みが少し面倒なので、戻り型を定義するためだけに->と入力する必要があります。 Pythonスタイルの構文について私が見ることができる唯一の引数は、1。Pythonに精通している人にもっとアピールすること、および2.実装が簡単であり、どちらも特に良い引数ではないと思います。 実装が簡単だと言っているわけではありません。もっと難しく、おそらく私のスキルレベルを超えていると思いますが、長期的にはそれだけの価値があると思います。

とにかく、それは私の2ペニーの価値です： smile:。 私はこれまでGDScriptでの開発を楽しんでおり、サウンドタイプシステムを備えていることを楽しみにしています。

Pythonはすでにこれをサポートしているので、私たちにできる最善のことはそこからコピーすることだと思います

varキーワードが嫌いな人のために、このようなものを許可するNimのような構文を追加することが可能かもしれません。

  a:int
  b:float
  c:char

const
  PI:float = 3.1416
  MAX:int = 100

なぜリターンタイプが必要なのか疑問に思います。リターンしていて、その出力が特定のタイプの変数に送られ、それらが一致しない場合は、スローされます。
コードを実行する前に、編集者がその間違いを見つけることができると思います。

リターンタイプvoidは私にはあまり意味がありません。その場合は、リターンタイプの定義を省略した方が簡単だと思います。

最後に、 ->は、戻り型がある場合は奇妙に思えますが、 func somefunc(): String: （多分？）のようなnimを実行しない可能性がありますが、私はそうではありません構文のような矢印のファンは、それも私にはあまり示さないので、方向性があるように見えますが、それとは何の関係もありません。ビット単位の演算>>と<<思い出させますが、それらはある意味で方向性があります。

__問題を解決するつもりはありませんでした__

ノードのすべての関数、その変数、およびその戻り型を読み取ることができるようになるため、場合によっては戻り型が重要であることがわかっていることがわかります。

今はあまり意味がないかもしれませんが、人々はプラグインや、それがどのように機能するかを非常に動的にすることができるゲームコードを書くことができるようになります。 IEの場合、プラグインに次の警告メッセージが表示される可能性があります。「このノードにはx戻り型の関数が必要ですが、参照しようとしているノードには、必要なメソッドシグネチャを持つメソッドがありません。」

私は、ユーザーフレンドリーのために（System.Reflectionを介して）このタイプのものをかなり使用するAIBehaviorと呼ばれるUnityのプラグインを作成しました。 私は文字通り、利用可能なメソッド名を入力するドロップダウンメニューを持っており、正しい署名を持つすべてのメソッドに基づいて、コールバックとして使用するメソッドを選択できるようにします。ゲームが実行されると、そのメソッドが呼び出されます。それが作られた状況。 アクセスしようとしているオブジェクト/スクリプトにメソッドが存在しない場合は、インスペクターにサンプルコードが表示されるため、コードをコピーして貼り付け、クラスの名前を変更するだけでスクリプトを作成できます。 :)

ですから、私の考えでは、できるだけ多くのスクリプト情報を持つことができれば、Godotはプラグイン作成者にとってはるかに拡張性が高くなります。

また、TypeScriptスタイルの構文（ var name: String = "Godot" ）は、動的言語に追加されるオプションの型指定の標準構文になっているため、望ましいと思います。

また、Python構文に従うことをお勧めします。
https://www.python.org/dev/peps/pep-0484/
https://docs.python.org/3/library/typing.html

これは、オプションの入力を使用して、同様の動的言語からGDScriptにアクセスする人々を支援します。

ところで、いつ/どのリリースでこれが実装されると期待できますか？ 3.1が言及されているのを見たことがありますか？

これはGodot3.1で利用できるはずです。

Cスタイルのプレフィックスがより複雑で、理解しにくく、読みにくく、Python構文などを使用する方が歓迎されるという議論について、すべてのドキュメントで、すべてのメソッドなどでそのCスタイルのプレフィックスを使用しているのではないでしょうか。 たとえば、カメラページから1つをすばやく引き出すだけで、 set_orthogonal ( float size, float z_near, float z_far )最初はよく理解できませんでしたが、学ぶのに少し時間がかかるだけで、その後は完全に理にかなっています。

こんにちは、ここで提案します。

理論的根拠：
静的型付けが必要だと思いますが、可能であれば、ユーザーに型を指定するように強制することは避けます。
すべての主要なコンパイル言語は、静的型推論に向かっています。
@reduzは、Godotソースコードの型推論があまり好きではないことを知っています。明確な観点から理解できます。 ただし、この妥協案は、静的型チェックの利点のほとんどを備えており、コーディング速度をそれほど妨げないため、GDScriptでは非常にうまく機能すると思います。
ただし、実装がより複雑かどうかはわかりません。
これには、代数的データ型としていくつかの追加のcostructが必要になります。
これがこの原則を使用する言語です

https://crystal-lang.org/docs/

下位互換性を維持するために、関数と変数を定義するためにいくつかの新しいキーワードが必要になります。 あるいは、静的型チェックを有効/無効にするための魔法のコメントがあるかもしれません。

これは、この種の型システムで何ができるかの例です（少しルビーを知っている人のために）

def test(x)
    return true if x
    return "This is false"
end

puts test(false).upcase
puts test(true)

出力：

Error in test.cr:6: undefined method 'upcase' for Bool (compile-time type is (Bool | String))

puts test(false).upcase
                 ^~~~~~

考え？

特にコード補完のためだけでなく、編集時に存在しないプロパティ/メソッドと無効な引数カウントをチェックするためにも、型推論を改善したいと思います。 オプションのタイピングが行われた後の2番目のステップのこの部分は、今のところ気にしないでください。

@ m4nu3lfの例はかなり進んでおり、実際には分岐に基づいて結果の型を推測しています。 コードの実行をシミュレートしないと、それがどのように行われるかがわかりません。コードは非常に複雑になる可能性があります。 @reduzが使いたいのかわかりません。

Godotの型システムは非常に厳密ですが、すべての変数はVariantです（つまり、任意の型を格納できます）。 これは互換性を損なうことを意図していないので、それらはそのようにとどまらなければなりません。 したがって、 var value = 42を実行しても、変数が整数であると自動的に想定されることはありません。特に、外部スクリプトによって自由に設定できるクラスレベルの変数の場合はそうです。 それは、型推論が何をすることができるかという束を妨げます（しかし、完了の目的のためにこのように使用することができます）。

前述のように、1つの可能性は、これをオプションにすることです。 スクリプトごとにこれを有効/無効にすることの価値があまり見られないので、おそらくプロジェクト設定です。 それでも、それは次のステップで考えられる別の提案です。

@vnen理論的には、「auto」や「let」などのパラメーター/戻り型/変数にいくつかの新しいキーワードを使用し、crystal-langの同じアルゴリズムを使用することで、コンパイル時に型を推測できます。
これは、完全な型推論を使用した静的型付けです。
あなたが持っているとしましょう
スクリプト内のauto my_field = 42は、タイプがintと単純に推測し、基になるバリアントをintのみに制限することができます。

ただし、その言語は単純な変数を超えています。 ブランチに応じて、タイプをタイプのサブセットに制限できます。
上記の例のように、戻り型は文字列またはブール値のみにすることができます。
しかし、これを行うには、

• 引数型の新しい組み合わせごとに関数をインスタンス化し、各戻り式の内部型を推測し、可能な戻り型のリストを戻り値の型として保存します。
• ブランチの場合、変数が割り当てられている可能性のあるすべてのブランチを調べて、特定の時間に変数の可能なすべてのタイプを推測します。 いつでも、バリアントのタイプをそれらに制限してください

さらに、「インスタンスの」条件などを確認する必要があります。

if my_var instanceof MyClass:
...

次に、if条件の本体でmy_varは「MyClass」にしかできないため、型はさらに制限されていることがわかります。
これに利点を持たせるには、可能なすべてのタイプで名前が共有されているメソッドを呼び出すか、フィールドにアクセスできる必要があります。
だから言いましょう

auto x = MyClass.new()
if (...):
   x = "hi"

この後、xはMyClassまたはStringのいずれかになります。 実行時エラーを回避するために、両方に共通のメソッドのみを呼び出すことができます。

これは私が当初考えていたものよりもはるかに多くの作業であると私は言います。
だから私はこれに戻りたいと思います。 将来的に実装できるかもしれませんし、誰かがcrystal-langのバインディングを書いてくれることを期待できるかもしれません。
いずれにせよ、それは本当にクールな機能だと思います

@ m4nu3lf私はあなたの要求が何であるかを理解しています、TypeScriptは非常に似ています（これは私がよりよく知っている言語です）。

ただし、GDScriptについて考慮すべきいくつかの問題があります。

• まず、それを実装するのは簡単ではありません。 他の言語がどのようにそれを実現するかを見ることができますが、それでも長い時間がかかります。 だから、一歩ずつ進んで、後で考えたいと思います。 TypeScriptは、Turbo PascalとC＃を作成したのと同じ人によって作成されたため、私にはない経験がたくさんあります。
• GDScriptは一度に1つのファイルをコンパイルします。 CrystalとTypeScriptはどちらも、プロジェクトを使用する前にプロジェクト全体をコンパイルする必要があります。 つまり、他のスクリプトやシングルトンとの相互作用をチェックするのは少し曇っています。
• シーンツリー。 get_node() （よく使用されます）では、どのノードタイプを取得するかを知ることは不可能です。 あなたはそれがNodeであることを知っているだけですが、それはどんなサブタイプでもかまいません。 load()を呼び出すとき、特に動的な名前で呼び出す場合は、リソースにも同じことが当てはまります。 _input(event) eventは任意のInputEventサブタイプである可能性があるため、 _input(event)にも同じ問題があります。

if my_var instanceof MyClass:
    ...

これは、コード補完のためにすでに推測されています。 実際の型チェックに再利用できます。 特にこのケースは些細なことですが、かなり複雑になる可能性があります。 たとえば、2番目の条件if some value == 42 and my_var is Spriteを追加すると、コード補完は機能しなくなります。

また、ユーザーからのフィードバックも聞きたいので、長い待ち時間の後にすべてを完璧にするよりも、すぐに利用できるものを用意することが（私にとって）重要です。

要約：型推論を改善したいのですが、少しずつ改善して段階的に行う必要があります。 オプションのタイピングが利用可能になると、残りは困難になります。

なぜこれが閉鎖されているのですか？

少し読み間違えました、私の悪いです。

接頭辞と接尾辞に戻る：UMLとKotlinはどちらも「：type」を使用します。
Basicも「DIMaasINT」を実行しました（「：」または「is」の代わりに「as」を使用しました）

@programathsそれから長い時間が経ち、何度も議論されてきました。 さらに、postfixを実装するPRがあるので、今は少し問題外です：smiley：

これを閉じる必要がありますか？

@ LeonardMeagher2 PRがマージされると、自動的に閉じられます。

@ bojidar-bgそれ自体が面白いので、postfixが使用される場所をいくつか追加したかっただけです。 UMLは、分析や技術者以外の人も対象としています。 Kotlinは、「効果的なJava」を実装しながら、Javaよりも快適でモダンになるように開発された言語です。

したがって、postfixが選択された理由を書き留める必要がある場合は、これらも含めることができます。 時々、人々はあなたがそれらをユーザーに関連付けない限り、理由を持ち、技術的なものを簡単に却下したいと思うでしょう。
（例：「パーサーはあいまいさを早期に解決でき、100倍の速度が得られます。つまり、同じプログラムをより高速にコンパイルでき、より多くのテストが可能になります）

素材があるのはいつもいいですね。 ;-)