【node.js】サーバサイドjavascript 5【Nashorn】 (796ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
731(1): デフォルトの名無しさん [sage] 2021/12/27(月) 05:27:18.08 ID:5b2Vj92V(1/3) AAS
>>730730(1): デフォルトの名無しさん [sage] 2021/12/27(月) 00:11:53.01 ID:Btn3kp2t(1/3) AAS
>>729
言いたかったこととしてはプロトタイプベースがクラスベースの機能包含しているとしても
静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
実行エンジンを実装してもあらゆるパスが評価できるわけでないので宣言的記法の方に軍配が上がると思うが
実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
flycheckってemacsのパッケージのことだと思うけどあれも静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
IDEのためだけではないというのはその通りで、途中から略して書いてしまっているが >>720 ではIDEや静的解析といっている
> 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
IDEの「実装」をプログラミング言語の「仕様」比較（スーパーセットかどうか）に含めるのがおかしい。
それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。
IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。
よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。
上下関係で言えばプログラミング言語の『仕様』が完全に上であって、
IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
> 静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
俺が使ったのはGoだけど、見た目は実際にコンパイルを走らせてそれをアノテートしてただけ。
でも確かにこれが一番生産性が高いんだよ。
当たり前だが、コンパイラはエラー時には何行目の何文字目でこけた、という情報を持ってる。
だから静的解析が目的ではなく、ソースコード作成時にエラーを表示する事が目的なら、これでいいんだよ。
最大のメリットは構文解釈を自前で実装する必要がない事。
構文解釈機の再開発をやめ、本体コンパイラのエラー情報をより詳細に出す事にリソースを突っ込み、
IDE側はその詳しいエラー情報を解釈してアノテートするだけに徹する。
これで言語側の仕様変更に自動的に追従するようになる。
IDEの数だけ構文解釈機を再開発するのは手段が目的化してる。
> 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
Flycheckは外部から呼んでるだけ。でもそれでコンパイラが吐くエラー（=静的エラー）は全て検出出来る。
しかも自前の実装もなしだから、最も生産性が高い。
自前の構文解釈機でコンパイラ/ビルドシステム以上のエラーを検出する気なら、
それはIDEではなくリンターと呼ぶべきだが、
それが出来るのなら、コンパイラ/ビルドシステムにそのリンターを内包して、
IDEはそのエラーを表示する事に徹するのが最も生産性が高い。
IDEで構文解釈するのではなく、エラーを出来るだけ早い段階で検出して修正するのが目的だから。
732(1): デフォルトの名無しさん [sage] 2021/12/27(月) 08:32:17.24 ID:Btn3kp2t(2/3) AAS
>>731
> IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
なぜそうあるべきなのですか？
近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
なぜか構文解析の話になっていますが意図してたのはintellisenseのような意味解析が必要な機能です
プロトタイプベースの記法では解析のためにコードの実行パスを追いかけプロトタイプの設定箇所を検出しなければならないのに対して
宣言的記法であればスコープ内のクラス宣言を見ればだいたい事足りるので実装難易度は大幅に異なるかと
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s