+ JavaScript の質問用スレッド vol.126 +

**デフォルトの名無しさん** · 2018/06/02(土) 14:31:23.04

JavaScript を自ら学ぶ人のための質問スレッドです。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

前スレ
+ JavaScript の質問用スレッド vol.125 +
https://mevius.5ch.net/test/read.cgi/tech/1518940081/

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）

**デフォルトの名無しさん** · 2019/01/21(月) 08:30:56.83

>>899
UIだけなら、CSSでボタンライクではないようにも変更できるわけでdiv要素を使う理由はない

**デフォルトの名無しさん** · 2019/01/21(月) 09:28:46.72

>>907
Enterキー押下時のclickイベント拾わない話じゃねーかとエスパーしてみる
それは他のブラウザでも同じなので、keydownイベント拾ってEnterキーだけ抽出してclickイベント時と同じ挙動をさせるしかないよね
shift/alt/meta/ctrlキー同時押しはもちろん排除するとしてさ

**デフォルトの名無しさん** · 2019/01/21(月) 12:48:28.69

>>909
それだけなら、tabindex属性付与だけで実装可能ではないか？
ボタンの何をエミュレーションしたいのかがわからん、には同意

**デフォルトの名無しさん** · 2019/01/21(月) 14:19:25.15

javascriptでreplaceを用いた特定の文字の置換ができないです。

// サーバーからデータを受信したとき
function onReceive(data) {
let json = JSON.parse(data);
let messages = document.getElementById('chat');
let li = document.createElement('li');

if(json.text == 'おい'){
json.text = 'オイオイオイ'
}

// JSONから必要なデータを取り出して、テキストにする
li.innerHTML = json.count + ":" + "<big>ななしさん</big>" + "ID:" + socket.id + " " + json.text;
// 画面に要素を追加する
messages.appendChild(li);
}

これがソースコードの一部です。
このソースコードで、「おい」と打ったら「オイオイオイ」と返ってくるのですが、
「あいうおいえお」と打ったら「あいうおいえお」と返ってきます。
本当は「あいうオイオイオイえお」と返ってきてほしいです。

**デフォルトの名無しさん** · 2019/01/21(月) 14:23:43.50

replace使ってないから

**デフォルトの名無しさん** · 2019/01/21(月) 14:27:21.86

if(json.text == 'おい'){
json.text = 'オイオイオイ'
}

上記の部分を

json.text.replace('おい','オイオイオイ')

にしたら何も表示されなくなってしまいました。

**デフォルトの名無しさん** · 2019/01/21(月) 14:31:42.02

>>913
だされた課題は自分でやれ

どうせ本当に出された問題は
「以下のコードをreplaceを使って書き直しましょう」
なんだろ？

答えを聞くな

**デフォルトの名無しさん** · 2019/01/21(月) 14:39:13.61

>>914
違います。
課題は課題なんですけど、
課題内容は「リアルタイム通信を使用してアプリケーションを作ろう」です。
課題の一部がどうしてもわからないので聞いています。

**デフォルトの名無しさん** · 2019/01/21(月) 14:40:34.76

>>914
的外れな返信でした。
ごめんなさい。

**デフォルトの名無しさん** · 2019/01/21(月) 14:45:16.85

replaceってヒントを貰ってるんだから、replaceについて調べればいいだけ

**デフォルトの名無しさん** · 2019/01/21(月) 16:01:51.07

>>917
おい、おっさん。
こんな時間に即返信するとかなにやってんの？ニート？ｗ
お前は「答えない」じゃなくて「答えられない」だろｗ
無能のくせにでしゃばるなよｗｗ

**デフォルトの名無しさん** · 2019/01/21(月) 16:05:59.24

無能ってすぐ人に答えを求めるよな
https://medaka.5ch.net/test/read.cgi/prog/1540885252/

やっぱり俺って有能なんだなあ
すぐ人に答えを求めたりしないしな

**デフォルトの名無しさん** · 2019/01/21(月) 17:34:06.91

# 詳しい人、知恵を貸してくれ。

div1 = document.createElement("div")、document.body.appendChild(div1)
として、div1 の style の position を absolute や fixed として、
style.top, style.left に座標を指定しても、以下のような affiliate がある場合、
newBox の margin の 100px と全く同じだけ、div1 の位置が下に下がってしまう。
仕様上は、position:absolute は、親要素であるところの body 要素の左上の点からの
相対位置で指定されるはずなのに、なぜだろう？
自分の理解では、以下の affiliate は、div1 などのもっとも年上の兄弟として
追加されるだけだから、div1 の位置には影響を与えないと思うんだが。

　var func = function(){
　　var parent = document.getElementsByTagName("body")[0];

　　var newBox = document.createElement("div");
　　newBox.setAttribute('id', 'vdbanner');
　　newBox.setAttribute("style","display:block!important;position:relative!important;top:0!important;left:0!important;margin:100px 0 !important;padding:0!important;text-align:center!important;");
　　newBox.innerHTML = "広告内容";
　　parent.insertBefore(newBox, parent.firstChild);
　}
　try {
　　window.addEventListener("load", func, false);
　}
　catch(e) {
　　window.attachEvent("onload", func);
　}

**デフォルトの名無しさん** · 2019/01/21(月) 17:53:37.90

長ったらしいので翻訳。まずimportant;は使うな

#vdbanner {
　display: block !important;
　position: relative !important;
　top: 0 !important;
　left: 0 !important;
　margin: 100px 0 !important;
　padding: 0 !important;
　text-align: center !important;
}

$(function() {
　$("<div/>", {id: 'vdbanner', text: '広告内容'}).prependTo('body');
});

**デフォルトの名無しさん** · 2019/01/21(月) 17:59:05.34

できたぞ、質問に答えられないバカ

var result = json.text
for(var i=0;i<json.text.length;i++){
if(json.text[i] == 'お' && json.text[i+1]=='い'){
var tagetString = json.text;
var reString = /おい/gi; // 複数を置換する時は"g"を、
// 大文字/小文字の区別をしない場合には"i"を指定します。
var repStrung = "オイオイオイ";
result = tagetString.replace(reString, repStrung);
}
}
じゃあな無能

**デフォルトの名無しさん** · 2019/01/21(月) 18:04:30.32

一行で書けるけど、じゃあなって言われたな。じゃあなｗｗｗｗ

**デフォルトの名無しさん** · 2019/01/21(月) 18:29:08.32

>>899
ボタン部分だけのクリックじゃなくて、
もう少し範囲を広くして、ボタンを含む、div で、クリックイベントを動作させたいのかね？

ボタン部分だけだと、範囲が狭くて、うまく押せない人がいるから

それと投稿者は、次に投稿する際に、名前欄に最初の投稿のレス番号を入れてくれ

**デフォルトの名無しさん** · 2019/01/21(月) 18:34:04.07

>>918
>おい、おっさん。
>こんな時間に即返信するとかなにやってんの？ニート？ｗ
>お前は「答えない」じゃなくて「答えられない」だろｗ
>無能のくせにでしゃばるなよｗｗ

>>911
も、同じID。PNnv4t9U

こいつは、いつもの荒らしだから、皆答えないように！

**デフォルトの名無しさん** · 2019/01/21(月) 18:36:35.58

>>920
web の質問は、こちらの板ではなく、web制作管理板の方へ書き込んでください！

**デフォルトの名無しさん** · 2019/01/21(月) 18:37:59.67

>>922 は酷いコードだなあ

**デフォルトの名無しさん** · 2019/01/21(月) 18:53:53.44

http://www.nowsmartsoft.shop/

承認欲求。自己顕示欲。
ちなみに引きこもり。

**デフォルトの名無しさん** · 2019/01/21(月) 18:59:45.68

>>921
それ、無料レンタルサーバー Xrea の Affiliate だよ。

結局、body 要素に、position: fixed; top:0px; を付けたら直った。

**デフォルトの名無しさん** · 2019/01/21(月) 19:03:58.42

>>922
var result = json.text.replace('おい', 'オイオイオイ')

**デフォルトの名無しさん** · 2019/01/21(月) 22:12:37.48

>>930
それを複数個作るとエラーが出るんです。

**デフォルトの名無しさん** · 2019/01/21(月) 22:20:46.95

>>931
var result = json.text.replace(/おい/g, 'オイオイオイ')

**デフォルトの名無しさん** · 2019/01/21(月) 23:50:10.62

ES6で新たに導入された式や文は
ES5.1の構文糖衣と考えて良いの？

**デフォルトの名無しさん** · 2019/01/21(月) 23:51:40.65

「ES5.1の構文糖衣」という表現がおかしい

**デフォルトの名無しさん** · 2019/01/22(火) 06:53:00.52

Class構文は再現できないので糖衣構文ではない

**デフォルトの名無しさん** · 2019/01/22(火) 09:26:06.80

>>935
> ECMAScript 2015 で導入された JavaScript クラスは、
> JavaScript にすでにあるプロトタイプベース継承の糖衣構文です。
> クラス構文は、新しいオブジェクト指向継承モデルを JavaScript に導入しているわけではありません。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Classes

**デフォルトの名無しさん** · 2019/01/22(火) 09:32:15.42

クラス構文だと関数で呼べないから違うものを導入してるよね

**デフォルトの名無しさん** · 2019/01/22(火) 10:20:50.82

糖衣構文かどうかにこだわるのってなんでだろう？
マウント取りたいだけな気がする

**デフォルトの名無しさん** · 2019/01/22(火) 12:50:28.60

>>936
よく読め
それはモデルとして、つまり抽象度の高い概念としての話であって
実際にES5で書き換えられるわけではない

**デフォルトの名無しさん** · 2019/01/22(火) 14:53:55.47

なんかそもそも糖衣構文という言葉をわかってないやつがいるみたいだ

糖衣構文の条件
× ECMAScript 2015で書いたのと同等のことを、ES5で（複雑に）書けること
○ ES5で書いたのと同等のことを、ECMAScript 2015で（シンプルに）書けること

>>939
お前変換の向きが逆

**デフォルトの名無しさん** · 2019/01/22(火) 15:28:28.10

それは絶対に違うね
新しい構文というのは問題を新しく解決する為に入れられるわけで
古いコードで書いてたコードがシンプルに書けるようになるものでない方が珍しい
そんな事を語っても仕方がない
古いコードで再現できるかどうかの方が意味がある

**デフォルトの名無しさん** · 2019/01/22(火) 16:20:43.54

また意味不明な

新しい構文の中で従来では複雑な書き方だったものを
シンプルに書けるようにしたものを特別に糖衣構文とよぶんだろ

誰が新しい構文はすべて糖衣構文って言ったんだ？
誰も言ってないだろ

**デフォルトの名無しさん** · 2019/01/22(火) 18:15:41.76

シンタックスシュガーがあるならシンタックスヌガーとかシンタックスハニーがあってもおかしくないよね

**デフォルトの名無しさん** · 2019/01/22(火) 18:31:09.00

シンタクティックシュガーな。

**デフォルトの名無しさん** · 2019/01/22(火) 19:07:04.65

>>942
度合いの問題だ
「ほぼシンプルに書けるようにすることが目的で導入されたもの」を糖衣構文と呼ぶのは分かる
ほかの要素を無視できるという意味での「ほぼ」だ
そうするとそのほぼというのは例えば感覚で8割～９割としよう
しかしClass構文でのその目的、重要度はせいぜい６～７割だということを言ってる
Class構文は従来__proto__を使わないとできなかったスタティックとプロトタイプメソッド両方の継承ということができる
これが俺にとって重要度・構文価値の～1/10
さらにnewTargetの存在によりビルトインクラスの継承ができるようになった
これが俺にとって重要度・構文価値の～3/10

少なくともこういう要素はClass構文を語る上で無視できる存在ではないだろう？
そうすると一般にClass構文は糖衣構文ということはできないというのが俺の主張だ
なのでそう言いたいのならコンテキストを絞った上で言わなければいけない
今回の場合も、もし「ES6で新たに導入された式や文は ES5.1の構文糖衣と考えて良い」と答えると
そういうClass構文などの無視できない重要なポイントを気にしていない、
下手すると気にしなくていいという発言になってしまうだろう？

君はそこを取るに足らないポイントだと考えるから、そう言えるんだろうが、
俺は>>933にそこももっと知っておいてほしい、説明したいと思うんだよ
そういう違いさ

**デフォルトの名無しさん** · 2019/01/22(火) 19:14:29.74

>>945
長ったらしくて読む気がしないが
要するにお前が言いたいのは、
class = 糖衣構文＋α って言いたいだけやろ？

**デフォルトの名無しさん** · 2019/01/22(火) 19:19:26.12

そして＋αの部分がclassでしか使えないのかといえばそうではなく
classを使わなくても、+αの機能は使えるから
やっぱりclassは糖衣構文

**デフォルトの名無しさん** · 2019/01/22(火) 19:33:50.03

>>947
Class構文のES5で代替不可能な機能はES6の他のより基本的な機能で代替可能だから、
ES6も入れたら糖衣構文と言ってもいいよ
でも今回はそうじゃないから
ES6の機能が、従来のES5の機能の糖衣構文と言えるかという話だから
その辺り俺は言葉に慎重だが、君は適当
そういう違いさ

**デフォルトの名無しさん** · 2019/01/22(火) 19:34:52.68

糖衣構文の反対はキムチ構文って呼ぶってことで
この話題終わりにしませんか？

**デフォルトの名無しさん** · 2019/01/22(火) 19:38:42.19

>>949
それでも良いよ
俺はどういう機能か説明したい気ならあるが
くだらない言い争いはもう沢山だから

**デフォルトの名無しさん** · 2019/01/22(火) 19:41:39.36

言葉に慎重なら糖衣構文っていう和訳も微妙

**デフォルトの名無しさん** · 2019/01/22(火) 19:54:31.00

構文的砂糖

**デフォルトの名無しさん** · 2019/01/22(火) 20:06:22.32

>>948
もしかして
ES5で今までやっていたことをclass構文で簡潔に書けるようになっても、
ES6で追加された機能をES5で実現できなければ糖衣構文ではないって言ってる？

意味不明なんだけど

**デフォルトの名無しさん** · 2019/01/22(火) 20:16:41.69

>>934で
> 「ES5.1の構文糖衣」という表現がおかしい
とせっかく俺が言ったのに

>>935がclassのことを持ち出すから
おかしくなったって自覚してるのかな？

classは糖衣構文だが、そもそも最初にES6の機能がとかいう言い方はおかしいって指摘した。
マッチポンプかよ。自分がclass限定の話にしておいてclass限定の話はしてないって

**デフォルトの名無しさん** · 2019/01/22(火) 22:05:19.77

話変わるけどジェネレーターは糖衣構文じゃないよねさすがに。

**デフォルトの名無しさん** · 2019/01/22(火) 22:38:28.82

>>953,954
意味不明なのはあんただ
俺は0.999だからNoとか0.001だからYesとか言うのは嫌いだし
そういう0か1かで糖衣構文「であるのかどうか」を話す気はない
たとえちょっと変な表現であろうと、今回の話の流れの上で糖衣構文「と呼んだほうが良いか」を
アナログ的に考えて、俺なりの想いを持って方が良い、悪いと話している

また俺はClass限定の話を始めたわけではない
わかりやすい一例としてまずClassでの事実を１つ挙げただけ
そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
変におかしな流れに誘導したのは君の方だよ

少なくとも俺は>>933を俺なりに解釈して話を始めた
そこで君が横から言葉の使い方がどうのこうのヤンヤン言って来ても知らんがなって感じ
君の脳内パーサではエラーが出たんだろうが、それをエラーですエラーですエラーですよって、うるさい目覚まし時計かって感じ
俺のゆるゆるパーサでは通ったんだから俺は話を進める、君は固まっとく、でいいじゃないか
俺までどうにかして止めようとする必要はない、俺はそういうのは嫌いだね

JSでも値をチェックして例外を吐くとかね
値をできるだけ加工したり用意の仕方を工夫して無効な値を極力作らないようにする方が俺は好きだ

ともかく君の定義ではそもそも話がおかしいのはおっしゃる通り
だからこそ俺はその定義は今回はそぐわないとしてるところに、わざわざその破綻する定義を持ってきて
ギーギーガーガーおかしいおかしい言われても　しつこいポンコツ機械かよって感じ
まあそんな感じ

**デフォルトの名無しさん** · 2019/01/22(火) 23:13:06.23

>>956
俺はclass = 糖衣構文＋αなんだから糖衣構文だって言ってるのに、
お前が、完璧じゃないから糖衣構文と言ってはいけないと言ってるんだろ
1じゃなければ0と言ってるのはお前だ

**デフォルトの名無しさん** · 2019/01/22(火) 23:13:38.81

頭イカれてるエンジニアによくある回答

**デフォルトの名無しさん** · 2019/01/22(火) 23:25:49.01

糖衣構文＋αじゃなくて、完璧に糖衣構文でしょ
糖衣構文＋αだったら糖衣構文とは言わないよ

**デフォルトの名無しさん** · 2019/01/22(火) 23:28:26.41

糖衣構文か否かの議論の果てにどんな結論があるんだろ

**デフォルトの名無しさん** · 2019/01/22(火) 23:30:12.08

>>959
同意

**デフォルトの名無しさん** · 2019/01/22(火) 23:46:44.98

var flagA = false && true || true;
変数flagAがtrueとなるのは、
false && trueがfalseになって、
false || true
true
となるからだと思うのですが、
ひとつ目がfalseなのに何故ショートサーキット評価されないのでしょうか。
最初に末尾まで見てて、&&の後ろがひとつの論理式である時だけショートサーキット評価されるってことですか。
あと、
var flagB = true || false && false;
flagBがtrueになるのは何故ですか。
true || falseがtrueになって、
true && false
false
になると思うんですが。

**デフォルトの名無しさん** · 2019/01/23(水) 00:10:25.21

>>959
いうだろ？
ES5で書いたものをclassで完璧に書けるんだぜ？
追加効果があったとしても関係ないだろ

それにそもそも糖衣構文って完全に同じものを
実現しなくてはいけないなんて制限はないんだが？

ほぼすべての糖衣構文はある機能に特化することでより便利にしているが
その反面あるきのう以外のことができなくなってる

他のどんなものが糖衣構文と呼ばれてるか考えてみなよ
糖衣構文という言葉に惑わされてるだけだろ

**デフォルトの名無しさん** · 2019/01/23(水) 00:11:52.34

>>960
それな。>>938ですでに俺が言ったことだが

**デフォルトの名無しさん** · 2019/01/23(水) 00:18:30.88

>>962
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
論理積と論理和では論理積の方が優先度が高く、短絡評価は論理積と論理和それぞれの評価について行われる

**デフォルトの名無しさん** · 2019/01/23(水) 00:18:39.97

一つ例を出してやる

C言語でswitch～caseはifの糖衣構文と呼ばれているが、
ifでやれることのすべてをswitch～caseでやれるわけじゃない
switch(a) ← 変数aとの比較限定になっている
この点においてswitchはifの制限版

また逆にswitch～caseのfall throughはifでは実現できない
この点において、switchは糖衣構文＋αの機能を持っていると言える

**デフォルトの名無しさん** · 2019/01/23(水) 00:20:16.03

>>962
ショートサーキットしてる
false && true || trueの二番目のtrueは評価されない
それと後者の答えは優先順位が違うから
&& は||より先に評価される
四則演算でいうと||が足し算で&&はかけ算

◆QZaw55cn4c · 2019/01/23(水) 00:29:11.43

>>966
＞逆にswitch～caseのfall throughはifでは実現できない
そんなことはないと思う
https://ideone.com/tVia2L

**デフォルトの名無しさん** · 2019/01/23(水) 00:59:58.12

QZは馬鹿だから無視でおｋ
「車は右側を走れるか」みたいな話は余計脱線するだけ

**デフォルトの名無しさん** · 2019/01/23(水) 01:06:50.82

ふむ。まあ要するにES6の機能をES5で実現できれば糖衣構文。
実現できなければ糖衣構文ではない。という定義は
完全に間違っているってことだな

**デフォルトの名無しさん** · 2019/01/23(水) 01:08:18.69

>>956
> そこから質問者が食いつけばClass構文が入ることによる新たな可能性を話すつもりだったのに
話したいことがあるのなら勝手に書け
そしてそれに食いつく奴が居るかどうかだろ
順序が逆だ

**デフォルトの名無しさん** · 2019/01/23(水) 13:27:42.36

せっかちなのは君の好きにすればいいけど
勝手に思い込んで突っ走って人に迷惑かけて……
もうクズの見本みたいな振る舞いしてる事に気が付いたほうがいいよ
勿体ないよ

**デフォルトの名無しさん** · 2019/01/23(水) 19:36:29.61

特に言い返すことは無いようで

**デフォルトの名無しさん** · 2019/01/24(木) 20:07:28.47

const foo = [1, 3, 5, 7, 9];
const bar = [3];

console.log(foo[bar]); // 7

このコードの意味がよくわかりません
状況からしてbar[0]の3を自動で取り出してfooの添え字にしてるように見えますが、そんな意味不明な動きしますか？
Cでいう*barみたいに配列の先頭アドレスから値を取り出してる？？

**デフォルトの名無しさん** · 2019/01/24(木) 20:18:20.31

>>974
そんな糞コードは理解出来なくていい
教科書なら捨てた方がいい

百歩譲って「添字はtoString()してるだけ」ということを教えたかったのなら、
数字と文字でやるべきだ

**デフォルトの名無しさん** · 2019/01/24(木) 20:28:18.18

>>975
すみません、業務で見たコードで、実際にはfoo相当の配列はオブジェクトの配列でした
先のコードは自分で実験用に動かしたコードです

なるほど、添え字に配列変数を指定すると、toStringメソッドが走る
配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
なので要素が数字かつ1つしかなければ、その数字を添字にしたのと同じことになる、ということでしょうか

**デフォルトの名無しさん** · 2019/01/24(木) 20:43:27.11

>>976
概ねその通りだが、俺は
> 配列変数のtoStringメソッドは角括弧なしで中身の要素をカンマつなぎする
これが仕様なのか環境依存なのかは知らんよ。

いずれにしても、「配列を添字として使う」事自体があり得ないだろ。
糞コードだし、修正すべきだよ。
動いているからバグとして検出されず、結果的に修正漏れになっている、ということかな。

なおその手の詳細な挙動を知りたければ、仕様書を読むしかない。
JavaScriptの仕様書は他言語で言う仕様書ではなく、実装指示書（詳細設計書）といった方が正しい。
だからオグジェクトの配列のアクセスの仕方（セマンティクス）がいちいち細かく書いてある。
その中で原則的には全てtoStringされていたはずなので、結果的にはそういう挙動になる。
つまり、

× > 添え字に配列変数を指定すると、toStringメソッドが走る
○　添え字は何であれ全てtoStringされる

だったはず。気になるなら仕様書を確認して。

**デフォルトの名無しさん** · 2019/01/24(木) 20:48:20.57

×　オグジェクトの配列の
○　オグジェクトや配列の

読める範囲ではあるが、若干混乱するかもしれないので念のため。

**デフォルトの名無しさん** · 2019/01/24(木) 20:48:26.62

>>977
丁寧にありがとうございます
どう見てもミスっぽいので直しときます
まさかこれで動くとは思わなかった……js怖い

**デフォルトの名無しさん** · 2019/01/24(木) 21:44:28.43

オグジェクトを訂正するのかと思った

**デフォルトの名無しさん** · 2019/01/25(金) 06:27:54.21

別にこの程度非難轟々するほどのコードじゃないだろう
暗黙の型変換がたった１回働いてるだけでしかないのだし
添字は必ずシンボルか文字列として評価されるってことも常識として知っておかないといけないこと

この程度にそんなに目くじらを立ててたらJSが読み書きしにくくなるというか
JSは避けてRustで書いてWasmにするとかした方が良いと思う

**デフォルトの名無しさん** · 2019/01/25(金) 11:52:33.10

普通にボロカスに言われるコードだと思う

**デフォルトの名無しさん** · 2019/01/25(金) 13:15:39.10

でも文字列を引数にとる既存の関数をタグ付きテンプレートとして呼び出せるのって['foo']が'foo'に変換される仕様のお陰なんだよなぁ

'hogefugapiyo'.split('fuga').join('hage');
↓
'hogefugapiyo'.split`fuga`.join`hage`

意味のないコードだけどあくまで例として。

**デフォルトの名無しさん** · 2019/01/25(金) 13:52:06.04

foo = [ 1, 3, 5, 7, 9 ];
bar = [ 3 ];
p foo[ bar ]

Ruby では、エラーになる。
配列から整数への、暗黙の型変換はできない

やっぱり、JS は、バグる。
怖い

**デフォルトの名無しさん** · 2019/01/25(金) 14:53:54.07

javascriptでいう関数ひとつ取ってもる～ピぃは
def
ブロック
Proc.new
proc
lambda
->
用途に合わせてどれが使えどれが使えないのか、使える場合変換は必要かどうか、変換なしで使える場合も挙動がどう異なるのか（同じように使える場合もすこしづつ挙動が異なるからｗ）あっちとこっちは相互にどういう変換方法があったか、等しっかり考えて作るもんなｗｗ
さすがるっピ！ｗｗｗ

**デフォルトの名無しさん** · 2019/01/25(金) 19:30:27.27

>>981みたいな奴が普通に居るのがJavaScriptコミュニティが腐ってる証拠な。
プログラミングを知らない癖に出来ると勘違いした馬鹿が間違ったことを吹聴しすぎてて、
馬鹿が再生産されまくっている。
とはいえ問題点は981以外には分かっているようだし、この話はもういいが。

他言語出身者なら、当初参考にするのはMDNだけにして、
個人が俺ツエーしてるだけのブログ等は全部無視した方がいい。
他言語ではあり得ない確率で間違ってるから、無駄にはまることになる。

emscripten/WebAssemblyが本格稼働するかどうか俺は懐疑的ではあるが、
実際にそうなったときに馬鹿JSerが一斉粛清されるかどうかは見物ではある。
「動けばいい」という基準で書いている限り、「動けばいい」程度のコードしか書けるようにはならない。
しかしこれがJSerの大半なのもまた事実だ。

一般的に「良いコード」とされる物を書けるかどうかはプログラマの技量のみに依存し、
JavaScriptだからといって書けない事はない。
ただ、どちらかというとJSはC寄りで、どんな糞コードでも書けてしまう。
ただこれは、単にJSerの技量が足りないだけであって、推奨されているわけではないので注意のこと。
>>979は今後色々と実感することになるとは思う。

**デフォルトの名無しさん** · 2019/01/25(金) 19:32:46.97

今はもうtypescriptで書くのが普通

**デフォルトの名無しさん** · 2019/01/25(金) 20:14:43.16

TypeScript使うのはReact使ってるときぐらいだろ？

**デフォルトの名無しさん** · 2019/01/25(金) 20:18:01.23

冗談きつい

**デフォルトの名無しさん** · 2019/01/25(金) 20:31:44.04

>>989
あ、すまん。ReactじゃなくてAngularだね

**デフォルトの名無しさん** · 2019/01/25(金) 20:37:08.43

そうじゃなくて、もう普通にみんな使ってるから

**デフォルトの名無しさん** · 2019/01/25(金) 21:42:00.59

c#に似せるならもっとc#にすればよかったのに
あの型の定義の仕方が嫌だ

**デフォルトの名無しさん** · 2019/01/25(金) 22:24:46.13

>>991
それはあんたの会社での話でしょ？
あんたの会社の話でもなく、Angular関係でもなく
TypeScriptが使われてることを証明する証拠でもあるの？

**デフォルトの名無しさん** · 2019/01/25(金) 22:31:45.82

こんなのあった。TypeScript圧倒的。
https://twitter.com/__sakito__/status/1071307378950266882
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2019/01/25(金) 22:50:09.67

>>994
どこが？ｗｗｗ

Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png

GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png

**デフォルトの名無しさん** · 2019/01/25(金) 23:35:19.53

今時型定義も入れずにnpmモジュール作ってるやつとか、白い目で見られるぞ

**デフォルトの名無しさん** · 2019/01/26(土) 00:03:22.84

>>996

ごく少数から？ｗｗｗ

Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png

GitHub Top Languages by Repositories Created: TypeScript is Not in the Top 5.
https://github.blog/2018-11-15-state-of-the-octoverse-top-programming-languages/
https://i.imgur.com/pZcCdjw.png

**デフォルトの名無しさん** · 2019/01/26(土) 00:10:36.62

>>997
下のページのtypescriptの伸びは見ないふりしてるの？

**デフォルトの名無しさん** · 2019/01/26(土) 00:31:22.48

>>998
延びた結果がこの差なんだよねｗｗｗ

Google Search Trends 2014–2018 JavaScript (Red) vs TypeScript (blue) Topic Interest
https://i.imgur.com/cmYy3rw.png

**デフォルトの名無しさん** · 2019/01/26(土) 00:32:01.77

javascript最高！
rupyキチガイ死ね！

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 237日 10時間 0分 38秒