【node.js】サーバサイドjavascript 5【Nashorn】 (796ﾚｽ)
上下前次1-新
663(1): 2021/11/25(木)07:46 ID:88pS2ZzI(1) AAS
>>660
外部ﾘﾝｸ:developer.mozilla.org
664: 2021/11/25(木)08:25 ID:QOEXsJ22(2/10) AAS
>>663
これ return と yield (と後置演算子もか？)はパーサの仕様バグだよな？
直感的じゃ無いという意味で。
665(1): 2021/11/25(木)08:37 ID:acYGqwrp(1) AAS
仕様だよ
お前の直感がおかしい
666(1): 2021/11/25(木)08:57 ID:QOEXsJ22(3/10) AAS
>>660
いや実際660はそうしてるだろ。俺も以前嵌った事があったし、
実際セミコロン必須の言語だとどこで切ってもいいから、660の書き方はよく見るよ。
俺はお前がおかしいと思うが。
結局これもMDNで説明するのに例外扱い("no LineTerminator here" 規則)になってるし。
統一された文法ではないよね。（=もっとましな仕様にする事も出来たし、実際他言語はそう）
667: 2021/11/25(木)08:57 ID:QOEXsJ22(4/10) AAS
すまん分かると思うが 666 は >>665 宛
668(1): 2021/11/25(木)09:45 ID:6PNOZvLH(1/3) AAS
>>666
その書き方よくみるというけど
1行で書けば見やすいのにわざわざ複数行で見にくくしている意図がわからない
669(1): 2021/11/25(木)10:02 ID:QOEXsJ22(5/10) AAS
>>668
そりゃ、そうした方が見やすいと思う人がそうするだけだよ。
お前がそう思わなければしなければいいだけ。
ただ実際、660にある公式のコードもそうなってるだろ。
俺も個人的には横に長いコードを書くけど、一般的には縦に長いコードの方が多いと思うよ。
670(1): 2021/11/25(木)10:13 ID:rnpiht7q(1/2) AAS
returnの直後に改行してないからASI関係なくないか？
671(1): 2021/11/25(木)10:19 ID:QOEXsJ22(6/10) AAS
>>670
660の「新しい記述方法だと動かない」とされてるコードは return gulp で改行してる。
660内の公式はこれが出来ない事を知ってるから、 gulp.src(...) で改行してる。（ただしreturnはないが)
672(1): 2021/11/25(木)10:26 ID:6PNOZvLH(2/3) AAS
>>669
それは長い行を分けて改行しているだけ
一方で>>660の人は長い行にならないのに無意味に改行しまくり
673(3): 2021/11/25(木)10:28 ID:rnpiht7q(2/2) AAS
>>671
return
gulp.src()
ならreturnの後にセミコロンが自動挿入されるけど
return gulp
.src()
ならgulpの後にセミコロンは自動挿入されないでしょ
省2
674(1): 2021/11/25(木)10:36 ID:QOEXsJ22(7/10) AAS
>>672
長さではなく、意味で切るんだよ。
>>673
> return gulp
> .src()
> ならgulpの後にセミコロンは自動挿入されないでしょ
されて gulp が返されるはずだぞ。
675(1): 2021/11/25(木)10:42 ID:6PNOZvLH(3/3) AAS
>>674
意味で切るならgulpと.src()の間で改行を入れてるのは明らかにおかしい
無意味な改行だ
676: 2021/11/25(木)10:42 ID:QOEXsJ22(8/10) AAS
>>673
すまん、674は間違い。
試してみたところ、確かに挿入されないようだ。
677: 2021/11/25(木)11:42 ID:QOEXsJ22(9/10) AAS
>>675
相手するだけ無駄っぽいが、そういうのは物によるんだよ。
そうした方が見やすいと思う奴がそうするだけ。
return ウンコ製造器675号
.src(ケーキ)
.pipe(胃)
.pipe(小腸);
省12
678(1): 2021/11/25(木)12:57 ID:K4FLN1Dn(1) AAS
んじゃ俺は括弧の後に半角スペースを入れるのを極めるわ。
679: 2021/11/25(木)13:45 ID:R4fLO2Lj(1) AAS
必死過ぎて笑えるｗ
680: 2021/11/25(木)14:09 ID:reZpBJt7(1) AAS
珍しく伸びてんなと思ったらこれだよ
681(1): 2021/11/25(木)19:42 ID:b7JhAcnH(1) AAS
.NET Standard が世界の中心と考えてる人でしょ
別スレで見た
682: 2021/11/25(木)21:14 ID:QOEXsJ22(10/10) AAS
>>678
ゆとりにはそれがお似合いだね
683: 2021/11/25(木)22:13 ID:HW7nta/v(2/3) AAS
610です。
仕事でレス遅くなりました。
>>673
ありがとうございます！
このコメントからピンときて修正したら無事に動作しました。
超初歩的なミスでした、、
こちらの書き方は関数の中にejs(gulp-ejsオブジェクト)を書いても動作しましたが
省6
684: 2021/11/25(木)22:25 ID:HW7nta/v(3/3) AAS
誤 610です。 = > 正 660です。
685: 2021/11/25(木)23:27 ID:nh0ZEMSE(2/2) AAS
漏れは、Ruby でも、パーサーの誤解釈を避けるため、
. を行末に置く
a.
b( ).
c( )
686: 2021/11/26(金)01:34 ID:KdVwfKAT(1) AAS
なんで Ruby が出てきた
687(1): 2021/11/26(金)22:15 ID:FIwAqG/H(1) AAS
スクリプト系は改行も終端になって駄目ね
688(1): 2021/11/26(金)23:57 ID:MbvsChzk(1) AAS
>>687
JavaScriptで駄目なのはreturnのみの行の時だけだよ
return
a
.b()
は駄目だけどこう書く人はいないから問題は起きることはない
return a
省2
689: 2021/11/27(土)09:09 ID:kX7QbhiL(1) AAS
そういうのはコーディング時にいちいち気にするよりlinterでチェックだな。
690(1): 2021/11/27(土)09:24 ID:LVgG7qhW(1/6) AAS
>>688
それを知ってないと嵌るだけの無駄仕様だよ。
セミコロンなしの筆頭だったAirbnbも諦めたようだし。
> ASI contains a few eccentric behaviors, though, and your code will break if JavaScript misinterprets your line break. These rules will become more complicated as new features become a part of JavaScript. Explicitly terminating your statements and configuring your linter to catch missing semicolons will help prevent you from encountering issues.
> 外部ﾘﾝｸ:github.com
他にセミコロンなしの有名ルール勢ってあったっけ？
return
省4
691(1): 2021/11/27(土)09:32 ID:MtgsfYs/(1/2) AAS
書き方にこだわりがあるならそうではない書き方と比べて◯◯の利点があると言わないと他人の理解は得られにくい。
好みだけの問題ならスクリプトの仕様に従うしかない。
692: 2021/11/27(土)09:36 ID:TUbuKQsw(1) AAS
自分はなりませんねとしか
693: 2021/11/27(土)09:41 ID:LVgG7qhW(2/6) AAS
>>681
俺向けではないと思うが、
return
'qwerty'
+'asdfgh';
の利点は見れば分かるとおり、インデントを揃えられる事だよ。
タグの方が分かりやすいかもしれんが一々引っかかると面倒なので止めただけ。
省6
694: 2021/11/27(土)09:42 ID:LVgG7qhW(3/6) AAS
すまん693内681は>>691
695: 2021/11/27(土)10:25 ID:wIEauZJC(1) AAS
お前ら何も考えずにPrettier使え
それが今のデファクトだ
696(1): 2021/11/27(土)11:22 ID:xgA8vuBV(1) AAS
>>690
Airbnbがセミコロンなしの筆頭って頭腐りすぎたろ
git時代に歴史改ざんしてもすぐにバレる
2012年にセミコロンの章が初めて書かれたときからAirbnbはセミコロン派だ
外部ﾘﾝｸ[md]:github.com
697(1): 2021/11/27(土)11:35 ID:LVgG7qhW(4/6) AAS
>>696
ならAirbnbというのは俺の勘違いだな。
俺がJSを始めた2013-14頃、有名なコーディングルールが4つほどあって、Airbnbが一番トンデモだった(が、人気は一番という話だった)
その中にはセミコロンを打つな、というルールもあった。誰か思えてないかね？
なお俺はgoogleのルールが一番マシっぽいのでそれを参考にした。(こちらはセミコロンあり）
698: 2021/11/27(土)11:43 ID:WAiK9igD(1) AAS
>>697
どこだか覚えてないけど、確かにどっかでセミコロン打たないで、短文を1行に書くときだけセミコロン使うてなの見たか聞いたりした記憶ある。
699: 2021/11/27(土)12:14 ID:LVgG7qhW(5/6) AAS
一応自分でも再確認しているところだが、
> Always use semicolons. (google)
> Use them. Never rely on ASI. (jQuery)
> あなたからセミコロンを奪おうとする反抗的な軍隊があるようです。でも確かに私達の伝統的な文化はまだ元気に生き残っています。だからコミュニティに従って、セミコロンを使いなさい！(Node)
> 外部ﾘﾝｸ:qiita.com
npmのもかなりトンデモだった記憶があり、改めて確認すると、打つな派だ。
> ;(x || y).performAction()
省12
700: 2021/11/27(土)12:30 ID:i1Pzoh/C(1) AAS
NodeはRyan Dahlが始めてセミコロンあり
npmはIsaac Z. Schlueterが始めてセミコロンなし
IsaacはNodeの2代目リーダーだけどNodeではセミコロンを書いてた
701(1): 2021/11/27(土)12:54 ID:XFyMXPdv(1) AAS
セミコロンレスの強硬派として有名なのはStandard
カスタマイズも許さない
外部ﾘﾝｸ:github.com
702: 2021/11/27(土)13:40 ID:LVgG7qhW(6/6) AAS
>>701
初コミット2015年なのにstandardと主張して他と違うルールとか、頭おかしいな。
とはいえ議論する時間が一番無駄というのは同意だが。
多分セミコロン無し言語出身者用のルールが一つは必要で、
それに向けてのstandard命名なのだろうけど、なんだかね。
703(1): 2021/11/27(土)13:49 ID:MtgsfYs/(2/2) AAS
文字列を「+」で繋げるのもうやめようよ。見にくいよ。
「´」(バッククォート)で括ればいいじゃん
704: 2021/11/27(土)13:51 ID:NSUO7OXD(1) AAS
>>703
このルール入れろ
外部ﾘﾝｸ:eslint.org
705: 2021/11/28(日)09:28 ID:yQx61O6E(1) AAS
javascriptならセミコロン無い方がいいかなぁ
706: 2021/12/14(火)18:36 ID:R85W1UAs(1) AAS
async/awaitってawaitしかしないから無駄じゃね？
707: 2021/12/26(日)08:00 ID:iIGCgNg3(1) AAS
Promise, async/await で無駄なのは、デタラメ解説の数々、ほぼ全滅だろ、酷い惨状だねー。
708: 2021/12/26(日)09:04 ID:S+a9i6vw(1/6) AAS
それを言ったらWeb系言語は全部デタラメ解説で駄目だろ
初心者が情報公開の練習として解説を書くからそうなる
709(1): 2021/12/26(日)10:12 ID:6ScHvZpk(1) AAS
それはしゃーない、正確さにこだわりすぎて萎縮する方がデメリットが大きい
読む方が気を付けて取捨選択するしかない
710: 2021/12/26(日)10:19 ID:jog3O69G(1) AAS
c++とかjavaとか含めて進化してる技術の古い解説はことごとくゴミ化してるし一緒だわな
711(1): 2021/12/26(日)11:04 ID:4h95DB/2(1/3) AAS
classは非推奨にして欲しい。
中途半端で使いにくい。
712(1): 2021/12/26(日)13:04 ID:PmcDL+gd(1/2) AAS
>>711
どういう所？
713: 2021/12/26(日)13:40 ID:S+a9i6vw(2/6) AAS
>>709
同意だが、C#はかなりマシ
一般的に上級者は初心者向けの説明なんて書きたくないものだが、
プログラミング自体について語りたい連中も多少はおり、そいつらを上手く取り込んでる
714(1): 2021/12/26(日)17:59 ID:4h95DB/2(2/3) AAS
>>712
上っ面だけのクラスベース。
内容はプロトタイプのまま。
715: 2021/12/26(日)18:08 ID:PnBrsUGe(1) AAS
上っ面といってもそこで整合とれていて内部の問題が表に現れないなら別に問題ないと思うが。
まぁ、中途半端というなら何かそういう部分が見えているということなんだろうが。
716: 2021/12/26(日)18:30 ID:oeLmweY9(1) AAS
定期的に呟いてる人だから気にせんでいいよ
717: 2021/12/26(日)18:50 ID:PmcDL+gd(2/2) AAS
>>714
オブジェクト指向的センスが無いと言う事だね
今の時代、両方出来ないとプロだと厳しいと思うがね
718(1): 2021/12/26(日)18:55 ID:S+a9i6vw(3/6) AAS
プロトタイプの方が表現出来る空間が広くて、実際にただの糖衣構文でクラスを実装出来てるだけだろ
クラスで閉じて使ってる限りプロトタイプの側面は見えないはずだが
混ぜて使うのってありだっけ？(class宣言した物にgetPrototypeOfとか)
class構文の時にどうプロトタイプが配置されるか仕様で確定してないと駄目だと思うが、これってしてるのか？
719(1): 2021/12/26(日)19:35 ID:kUhTwtcg(1) AAS
GoやRustなんかの新しい言語がクラスベースのオブジェクト指向を採用しないご時世
時代遅れとなったC++やJava風のクラス構文を導入する必要はなかったわな
TC39的にはES4で入れ損なったから悲願だったんだろうけど
720(2): 2021/12/26(日)20:25 ID:M+F+5/6j(1/3) AAS
プロトタイプベースのオブジェクト指向ってIDEや静的型付けと相性悪いのでは
721(1): 2021/12/26(日)20:48 ID:S+a9i6vw(4/6) AAS
>>720
仮にそうだとしても、IDEの都合を優先してプログラミング言語を簡素化するのは完全に本末転倒だろ
初心者専用のオモチャが欲しければScratchで満足しとけ
722(1): 2021/12/26(日)20:54 ID:M+F+5/6j(2/3) AAS
>>721
既存との互換を保ったまま機能追加されてるわけだから言語自体は簡素化されたのてはなく複雑化されたのでは
それはさておき従来の機能が使えなくなるわけでもなく何が不満なのかわからない
723(2): 2021/12/26(日)21:02 ID:4h95DB/2(3/3) AAS
>>718
してない。
だから細かい設定が解りづらい。
724(1): 2021/12/26(日)21:18 ID:S+a9i6vw(5/6) AAS
>>722
糖衣構文を導入した分言語は複雑化してるし、IDEも余計に対応する必要がある。
IDEを優先するなら何もしないのが最善。
（もちろん仕様を削れるのが最善だが、JSの場合はこれはかなり無理なので）
>>723
仕様で確定してないのなら、混ぜて使う事は禁止だし、
クラスで閉じて使う分にはプロトタイプベースは見えないから問題ないだろ。
省1
725(1): 2021/12/26(日)21:26 ID:PIvfFszt(1/2) AAS
>>723
ECMAScriptの仕様書も読んだことない低脳が堂々と嘘を書くなよ
ES2020の14.6.12
726: 2021/12/26(日)21:33 ID:PIvfFszt(2/2) AAS
>>725
自己レス「ES2020の14.6.13」の書き間違い
727(1): 2021/12/26(日)22:43 ID:M+F+5/6j(3/3) AAS
>>724
そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ
例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う
構文解析なんかは大して難しい話ではない
728: 2021/12/26(日)22:59 ID:vgGpFQt6(1) AAS
実際にTypeScriptはinterface導入してるし何も問題ないだろ
729(1): 2021/12/26(日)23:27 ID:S+a9i6vw(6/6) AAS
>>727
最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、
IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。
プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。
IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。
IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、
一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。
省8
730(1): 2021/12/27(月)00:11 ID:Btn3kp2t(1/3) AAS
>>729
言いたかったこととしてはプロトタイプベースがクラスベースの機能包含しているとしても
静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
実行エンジンを実装してもあらゆるパスが評価できるわけでないので宣言的記法の方に軍配が上がると思うが
実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
flycheckってemacsのパッケージのことだと思うけどあれも静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
IDEのためだけではないというのはその通りで、途中から略して書いてしまっているが >>720 ではIDEや静的解析といっている
731(1): 2021/12/27(月)05:27 ID:5b2Vj92V(1/3) AAS
>>730
> 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
IDEの「実装」をプログラミング言語の「仕様」比較（スーパーセットかどうか）に含めるのがおかしい。
それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。
IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。
よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。
上下関係で言えばプログラミング言語の『仕様』が完全に上であって、
省19
732(1): 2021/12/27(月)08:32 ID:Btn3kp2t(2/3) AAS
>>731
> IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
なぜそうあるべきなのですか？
近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
なぜか構文解析の話になっていますが意図してたのはintellisenseのような意味解析が必要な機能です
プロトタイプベースの記法では解析のためにコードの実行パスを追いかけプロトタイプの設定箇所を検出しなければならないのに対して
省1
733(1): 2021/12/27(月)09:13 ID:mFj7RPUl(1/2) AAS
今時プロトタイプベースがぁ、って言ってるのが時代遅れじゃねーの。
クラスベースじゃないからってRustやGoを出してるがそれらはプロトタイプベースですらないわけで。
734(1): 2021/12/27(月)09:41 ID:VqPkBZyA(1) AAS
>>733
>>719はクラスベースを時代遅れと書いたんだが
ぶっちゃけオブジェクト指向が過去のものになってきてるのみんな分かってるだろ
735(1): 2021/12/27(月)10:22 ID:5b2Vj92V(2/3) AAS
>>732
> 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
「多い」というのならまず具体的に名前を複数挙げてみろ。
出来なければそれは君の妄想だね。
> また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
違うぞ。それは今の話に関係ない。（どっちでもいい）
> 意図してたのはintellisenseのような意味解析が必要な機能です
省17
736: 2021/12/27(月)10:51 ID:gEDfakwV(1) AAS
×クラスベース
○クラス構文
クラス構文で書いてもプロトタイプベースなのは変わらん
737(1): 2021/12/27(月)11:21 ID:mFj7RPUl(2/2) AAS
>>734
確かにクラスベースがってよりオブジェクト指向が時代遅れって感じだね。
JS自体は関数プログラミングもいける。
738: 2021/12/27(月)11:22 ID:lxgQYw9b(1) AAS
言語仕様も分かってないIDEも使ってない部外者の素人同士が長文レスバって地獄だな
739(1): 2021/12/27(月)11:54 ID:Btn3kp2t(3/3) AAS
>>735
> 「多い」というのならまず具体的に名前を複数挙げてみろ。
例えばgolangやrustはコアチームがツール開発に積極的ですね
ツールのチームがコア言語に対してフィードバックしていたりする
> eval出来る環境があり、それが一番近道なら、やればいいだけ。
"構文解釈機" という言葉を使っているから静的解析を意図してるのかと思ったけど動的解析も含んで言っていたのね
それで実用に耐えうる速度と精度が実現できるならそういうアプローチもありかもね
省3
740: 2021/12/27(月)12:21 ID:VwNgBMvN(1) AAS
オブジェクト指向ならではの筆頭が継承だから継承が忌避されてる＝オブジェクト指向が忌避されてるってことよ
OOPLが提供していた継承以外の特性の多く(カプセル化など)は抽象データ型から来ていてそれは時代遅れになってないし忌避されてもいない
741(1): 2021/12/27(月)13:11 ID:+2NyFcdP(1) AAS
クラスの定義だけど、
classとfunctionを混在した書き方でも問題ないの？
742: 2021/12/27(月)13:40 ID:Uq9DqbRx(1) AAS
>>741
混在した書き方っての次第だが
class A {}
A.prototype.x = () => {}
a = new A()
a.x()
こんなのは当たり前に動くぞ
省2
743: 2021/12/27(月)15:00 ID:5b2Vj92V(3/3) AAS
>>739
> 例えばgolangやrustはコアチームがツール開発に積極的ですね
それで、それらの言語のどの仕様がIDEの都合で採用されたものなの？
> 藁人形論法はやめてくれ
なら最初から分かるように主張しろ。
何が言いたいか分からないからエスパーして複数挙げてみただけ。
馬鹿は無視してきっちり自分の意見を書ききれ。
省18
上下前次1-新書関写板覧索設栞歴
あと 53 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.032s