私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.137 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>101
なるほど
なるほど
Mapいいんだけどさぁ、重厚長大過ぎるよ。
使いどころはあるけど普段使いしないよ。
単なる組み込みクラスでリテラルも無くsetget系APIも目にうるさい。
顧客が本当に求めていたもの： 列挙時順序保証のオーダードオブジェクトリテラル
const list = #{variable1, variable2, variable3};
で>>81の順序が保証されるみたいな。
これをfor inしたときはプロトタイプ辿らないみたいな挙動なら完璧。
使いどころはあるけど普段使いしないよ。
単なる組み込みクラスでリテラルも無くsetget系APIも目にうるさい。
顧客が本当に求めていたもの： 列挙時順序保証のオーダードオブジェクトリテラル
const list = #{variable1, variable2, variable3};
で>>81の順序が保証されるみたいな。
これをfor inしたときはプロトタイプ辿らないみたいな挙動なら完璧。
たしかにget/setはダサい
[]でアクセスできてこそmap
TypedArrayが[]アクセスできるのは何でだっけ
[]でアクセスできてこそmap
TypedArrayが[]アクセスできるのは何でだっけ
>>106
後方互換性を考慮してあの設計なのだろう
後方互換性を考慮してあの設計なのだろう
テンプレートリテラル`～`に対するタグ付きテンプレートリテラルhoge`～`みたいに配列リテラル[～]、オブジェクトリテラル{～}に対してもfuga[～]、piyo{～}みたいにユーザー定義の道を開いてくれると嬉しい。
配列リテラルについては無理か…
fugaに対するキーワードアクセスと区別つかないもんな。
配列リテラルについては無理か…
fugaに対するキーワードアクセスと区別つかないもんな。
>>110
タグ付きテンプレートリテラルとは？
タグ付きテンプレートリテラルとは？
>>111
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/template_strings#タグ付けされたTemplate_literal
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/template_strings#タグ付けされたTemplate_literal
>>113
styledComponentのAPIがこれ使ってた気がするな…
まあリフレクションAPIとかと同じでフレームワークやライブラリを作る人が使う機能で一般ユーザーは提供されるAPIにしたがってhoge`～`するだけだよ。
styledComponentのAPIがこれ使ってた気がするな…
まあリフレクションAPIとかと同じでフレームワークやライブラリを作る人が使う機能で一般ユーザーは提供されるAPIにしたがってhoge`～`するだけだよ。
>>114
なるほど、タグ付きテンプレートリテラルに最適化されたAPIを作れるのが利点か
なるほど、タグ付きテンプレートリテラルに最適化されたAPIを作れるのが利点か
tag(``)がtag``って書けるのがナウいんだよ！うるせーな！！
>>118
違います。
tag(`a${1}b`)だと関数tagは１つの文字列a1bしか受け取れません。
tag`a${1}b`だと関数tagは配列(厳密にはrawも含むが)['a', 'b']と1がそのまま受け取れます。
違います。
tag(`a${1}b`)だと関数tagは１つの文字列a1bしか受け取れません。
tag`a${1}b`だと関数tagは配列(厳密にはrawも含むが)['a', 'b']と1がそのまま受け取れます。
>>110
tc39眺めてたらそういう話なくもないんだな。
suffix方式にすれば配列リテラルも行けるらしい。
http://github.com/tc39/proposal-extended-numeric-literals/blob/master/README.md#extended-maparray-literals
tc39眺めてたらそういう話なくもないんだな。
suffix方式にすれば配列リテラルも行けるらしい。
http://github.com/tc39/proposal-extended-numeric-literals/blob/master/README.md#extended-maparray-literals
眺めてたらってそういう話もなくはないんだなって。。。
もういい加減にしてくれ
この手の話は何度もES6から出てただろうが
そして何度も挙がるものって２種類あって
毎回進歩するものとそうでないもの
これは後者だろうが
そのへんなんにも追っかけてなくてニュアンス理解してないくせに
一瞬調べて無責任に引っ張ってくるってどうよお前
お前どうよ？それ
もういい加減にしてくれ
この手の話は何度もES6から出てただろうが
そして何度も挙がるものって２種類あって
毎回進歩するものとそうでないもの
これは後者だろうが
そのへんなんにも追っかけてなくてニュアンス理解してないくせに
一瞬調べて無責任に引っ張ってくるってどうよお前
お前どうよ？それ
無責任って何を当たり前なことを…
なんで俺が責任とるんだよバーカｗ
なんで俺が責任とるんだよバーカｗ
>>77
let variable1 = "";
let variable2 = [];
let variable3 = 12;
let list = [];
list.push({variable1});
list.push({variable2});
list.push({variable3});
for (let obj of list) {
alert(Object.keys(obj)[0]);
}
let variable1 = "";
let variable2 = [];
let variable3 = 12;
let list = [];
list.push({variable1});
list.push({variable2});
list.push({variable3});
for (let obj of list) {
alert(Object.keys(obj)[0]);
}
名前はスコープで管理されているのでwithを使うしかない
それでも原理的に確実ではないのでwith-proxyを使うか
それでも原理的に確実ではないのでwith-proxyを使うか
リストに追加した後も変数名残そうと思ったらwith-proxyだけじゃ足りないだろ
value-proxyが導入されたら組み合わせて可能かもしれないが
value-proxyが導入されたら組み合わせて可能かもしれないが
with-proxyて何？検索しても出てこない(´；ω；`)
なんでみんな知ってるんや…
なんでみんな知ってるんや…
そのまんま
with(new Proxy(......)){}
のことでしょ
こうしたら変数アクセスをほぼほぼプロキシできる
例えば__scope__でスコープオブジェクトにアクセスできるようにしたり
$GetVariableName(a) // 'a'
みたいな事とかいろいろできる
with(new Proxy(......)){}
のことでしょ
こうしたら変数アクセスをほぼほぼプロキシできる
例えば__scope__でスコープオブジェクトにアクセスできるようにしたり
$GetVariableName(a) // 'a'
みたいな事とかいろいろできる
他にも分数だったりbignum同士の四則演算もできたはず
$BEGIN_BIGNUM
a = '12345678901234567890'
b = '23456789012345678901'
c = a + b
$END_BIGNUM
c // '35802467913580246791'
って感じでできるようにプロダクトで使ったことある
$BEGIN_BIGNUM
a = '12345678901234567890'
b = '23456789012345678901'
c = a + b
$END_BIGNUM
c // '35802467913580246791'
って感じでできるようにプロダクトで使ったことある
原理的に変数アクセスがプロキシできたらできることなら何でもできるよ
変数名を変えても影響でないでしょ
メタ処理で決め打たなければいいだけなんだから
メタ処理で決め打たなければいいだけなんだから
論よりコード。
with proxyでゴチャゴチャ言ってる人たちは上の奴らと違ってコードを出さずにイキってばかり。
with proxyでゴチャゴチャ言ってる人たちは上の奴らと違ってコードを出さずにイキってばかり。
すまんが俺はコードより論派なんでね
糞面倒な糞コードをわざわざ書こうとは思わん
特に楽しくアイディアを語り合ってるのをイキってるとか言うやつの言うことは聞きたくないね
素直なかわい子ちゃんのお願いだったら聞いてやる
糞面倒な糞コードをわざわざ書こうとは思わん
特に楽しくアイディアを語り合ってるのをイキってるとか言うやつの言うことは聞きたくないね
素直なかわい子ちゃんのお願いだったら聞いてやる
てかwithproxyとやらでも順序は保証できないじゃんｗ
順序保証しなくていいなら>>81でいいじゃんｗｗ
ダラダラproxy書く意味まるでナシｗｗｗ
proxyproxy言ってる人は何か勘違いしているのでは？ｗｗｗｗ
論は論でも机上の空論ｗｗｗｗｗ
順序保証しなくていいなら>>81でいいじゃんｗｗ
ダラダラproxy書く意味まるでナシｗｗｗ
proxyproxy言ってる人は何か勘違いしているのでは？ｗｗｗｗ
論は論でも机上の空論ｗｗｗｗｗ
こいつ何いってんだ？
listに入れたものだとvalue-proxy使わないと難しいねって最初から話されてるだろ
勿論すべての箇所で値が欲しいときはSLOVE(x)、名前が欲しいときはNAME(x)を使う
つまり
for(let i = 0; i < SLOVE(list).length; i++)
{
alert(NAME(SLOVE(list)[i])); //variable1 variable2 variable3と順番に表示
}
みたいに書いてもいいっていうなら原理的に可能だが
listに入れたものだとvalue-proxy使わないと難しいねって最初から話されてるだろ
勿論すべての箇所で値が欲しいときはSLOVE(x)、名前が欲しいときはNAME(x)を使う
つまり
for(let i = 0; i < SLOVE(list).length; i++)
{
alert(NAME(SLOVE(list)[i])); //variable1 variable2 variable3と順番に表示
}
みたいに書いてもいいっていうなら原理的に可能だが
あと、ただ変数を列挙したいだけなら上で挙がったように
__scope__みたいなの１つだけ特別扱いして
__scope__.keys()みたいなのを定義すればいいだけだと思うよ
そのままだとすべて列挙することになるけど
まあどうして列挙したいのかわからんが、例えばデバッグのためなら
変数名のパターンで絞り込むとか、そのくらいのことで実際はOKかもしれんよ
__scope__みたいなの１つだけ特別扱いして
__scope__.keys()みたいなのを定義すればいいだけだと思うよ
そのままだとすべて列挙することになるけど
まあどうして列挙したいのかわからんが、例えばデバッグのためなら
変数名のパターンで絞り込むとか、そのくらいのことで実際はOKかもしれんよ
>>77
趣向を変えてタグ付きテンプレートでやってみたよ！
let list_keys = strs => [eval(strs[0]), strs[0].replace(/\[(.*)\]/, '$1').split(/ *, */)];
let variable1 = '';
let variable2 = [];
let variable3 = 12;
let [list, keys] = list_keys`[variable1, variable2, variable3]`;
for (let i = 0; i < list.length; i++) {
alert(keys[i]);
}
趣向を変えてタグ付きテンプレートでやってみたよ！
let list_keys = strs => [eval(strs[0]), strs[0].replace(/\[(.*)\]/, '$1').split(/ *, */)];
let variable1 = '';
let variable2 = [];
let variable3 = 12;
let [list, keys] = list_keys`[variable1, variable2, variable3]`;
for (let i = 0; i < list.length; i++) {
alert(keys[i]);
}
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.107 + (1001) - [97%] - 2013/9/7 10:16
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
トップメニューへ / →のくす牧場書庫について