Array/配列

[azu]

#17 基礎文法/オブジェクト

配列についての章。

アウトライン:

• https://github.com/asciidwango/js-primer/blob/master/source/OUTLINE.md#%E9%85%8D%E5%88%97

[azu]

Arrayのメソッドについては事前に色々説明している #68
Arrayオブジェクト というタイトルを見た時に何が期待されるかを考える必要がありそう。
#4 TODOアプリでも配列を使ってるので、なぜ配列なのか、逆になぜ◯◯ではないのかという事を書いていった方がユースケースが出てくるかも。

Arrayのメソッド紹介をどこまで自然にやるかが問題になりそう。
多分メソッドというよりもArrayとしての性質を使うためのメソッドを紹介するという流れにしたい。
(rangeとか微妙に足りないやつをどうしようかな)

Array.prototype.reduceRight() とか以外大体使うような気がしている。
後は length の特性を解説するべきかどうかという

[lacolaco]

ここに限った話ではないけど、表記的には Array.prototype.map でいくんですかね？ Array#map みたいなJavaっぽい書き方もありますが
これってどこかにまとめられてましたっけ

[azu]

@laco0416 まとまってないので、決めて。

forEachメソッド
Array#forEach
array.forEach
Array.prototype.forEach

どれかの表記にまとめたい感じがする。
https://github.com/asciidwango/js-primer/pull/80#discussion_r70064981

今は タイトル系は Array.prototype.forEach
文章中は forEachメソッド にしてる

[lacolaco]

サンプルコードベースで説明するなら array.forEach が一番自然な気がする。追加の説明がいらないし
でもMDNとかで調べようとすると https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/map はArray.prototype.mapだから、Array.prototype.forEach がarrayのインスタンスメソッドを表してるってことを書いてないとどのみち困りそう。
#はない方向でよさそう

これはprhでしばれるのかな…

[twada]

インスタンスメソッドとクラスメソッドのある言語では

• Array#forEach はインスタンスメソッド
• Array.forEach はクラスメソッド

という書き分けをよく見ますね

[azu]

Promise本だとこういう定義にしてた

http://azu.github.io/promises-book/#_%E8%A1%A8%E8%A8%98%E6%B3%95

インスタンスメソッドを instance#method という表記で示す。

例えば、Promise#then という表記は、Promiseのインスタンスオブジェクトの then というメソッドを示しています。

オブジェクトメソッドを object.method という表記で示す。

これはJavaScriptの意味そのままで、Promise.all なら静的メソッドの事を示しています。

[azu]

Object#instance はいずれにしても触れたほうがよさそうな気がする。
普通に他の文章でも出てくることがあるし、JavaScriptだと結構見かけるので。

Using a number sign (#) has emerged as a popular convention for describing prototype methods. For example, you will often see Car.prototype.shift written simply as Car#shift.
-- Lerning JavaScript 3rd

ただ、tc39/proposal-private-fields: A Private Fields Proposal for ECMAScriptが仮に入ったらこの記法どうなるんだろ的なのがよぎった。

[azu]

http://exploringjs.com/es6/ は

C constructor
Static C methods
C.prototype methods

で、クラスメソッドとprototypeメソッドはそれぞれそのままの表記。

• Array.from
• Array.prototype.forEach

文中のインスタンスメソッドは map() とか何もつけずに書いてる。

[azu]

どちらにしてもprhでは判定するの無理だと思う。
自分は Array.from とかはコードと言う認識なので、 backtickで囲むと思うし。
それ専用のルール書かないと厳しい。

機械的に間違いが見つけやすい表記だと嬉しい

[azu]

http://yshibata.blog.so-net.ne.jp/2016-08-13
API設計の基礎

Array で何となく思い浮かぶ話

[azu]

全体的基礎文法の前半(forとかの構文)は読み込み系の処理が多い気がする。
Arrayオブジェクトとかの各オブジェクトの章で書き込む処理を扱う際になにに気をつけるべきがテーマにおいたほうが良いのかも。
Arrayなら基本的にmutableである点とか、どうやったら読みやすいコードを書けるのかみたいな。
例えばnullチェックを不要にするにはとか

[azu]

push/pop、indexOf/find or includeの話
mutableなのでimmuableにしてみるslice,...,concatの話
scopeなtraveseをしてみるネストした配列

[azu]

クリーンコード p159

• nullを返さない
• nullを渡さない

return null or return [] の話

reutrn null した場合の問題は「nullチェックしてください」という小さく大きな要求が発生する。
nullチェックを一つ忘れればアプリケーションは停止してしまう。
nullチェック忘れという言葉で片付けるものではなく、nullチェックが多すぎる問題になってしまう。
そのため、nullを返すのではなく、例外を出すか、スペシャルケースオブジェクトを返すようにする。
この場合は単純に空の配列を返すのが良いという話。

[azu]

new Array(len)と[undefined, ...]の違い - Qiita
これ結構面白い挙動だなー。Rangeみたいなことをやろうとしてハマることがありそう。
Array#fillが有用なケース

[azu]

• 意外すぎる"未定義"の配列とその挙動 - Qiita
• 意外すぎる"未定義"の配列とその挙動 - Panda Noir

疎な配列の文章表現が結構難しい。
プロパティのキーそのものがないということと値がない(undefined)と区別するうまい表現をしないといけない

ちゃんとやるなら配列もオブジェクトだよってところからやる感じなのかな(あんまりこういう意識でかかないから説明のためっぽいカンジがするのが微妙)

{ 
  "0": 0,
  "1" : 2,
  "length": 2
}

[azu]

• Gozala/antimutable-array: Immutable alternatives to built-in array operators
• Pure javascript immutable arrays

[azu]

Array#copyWithIn　について調べてたけど、普通の人が使うユースケースが分からない。。
これTypedArrayからきてるのかな

• Array.prototype.copyWithinが実装された - JS.next
• Firefox 32(Nightly) で Array.prototype.copyWithin が実装された - hogehoge @teramako
• 18. New Array features
• ES6 Array Extensions in Depth

[azu]

JavaScript標準ライブラリの使い方超入門（3）：JavaScriptで配列を扱うArrayとスタック、LIFO、FIFOの基本 (1/6) - ＠IT
メソッドの分類を見てた

[azu]

ひとまずざーと書いてみた
JavaScriptの配列のパターン | Web Scratch
ここから色々削ったり、順番を整理したり説明を書いたりしたらできるかな。
参照型のところがちゃんと理解できてないからか上手く説明できなかった感じがする。
#145 で一度説明してから、Arrayではもう一度触れ直す感じかな

[azu]

https://github.com/asciidwango/js-primer/blob/master/source/OUTLINE.md#%E9%85%8D%E5%88%97
Arrayのアウトラインをここに書いてるけど、結構広い感じ。
書きながらアウトラインへ反映を繰り返してると、だんだん統合されてくる。

[azu]

やりたいこととしては 十一章第一回　配列 — JavaScript初級者から中級者になろう — uhyohyo.net が近いのかもなー。

アウトラインベースで書き始めてみて、大体以下の3つが書きたいんだなと思ってきた。

• 基本的なメソッド(破壊的なやつばかり)
• コピー、破壊的じゃないメソッドとそれを推奨する理由
• 配列のパターン(メソッドチェーンとか高階関数、return [])

2番目のやつが異常に難しくて納得できるように書くのが厳しい感じ。
破壊的なメソッドをそのままつかちゃうと変数の名前から意味が抜けていくとか、読むときに動きをトレースする難しさとかがあるという感じの話になる。
配列はやっぱりMutableとImmutableがごちゃまぜ感が辛くて、それをどうにかするため LodashとかUnderscoreみたいなutilライブラリが異常な数あるんだなーという感覚。
(直に扱うのが難しい場合はライブラリを使いましょうという感じの話もありといえばありかな)

[azu]

ES5でArray subclass

How ECMAScript 5 still does not allow to subclass array — Perfection Kills

[azu]

javascript - Object.assign()の評価タイミング（？）について - スタック・オーバーフロー

Array#fill({}) の動作 プリミティブ値以外を渡すことを考えたことなかったのでよくよく考えるとそうなのかー

[azu]

https://employment.en-japan.com/engineerhub/entry/2017/07/10/110000
これを読んでいて、先にImmutable、mutableの話をするべきかを考えていたけど、
やっぱり先にそういう違いがあるという話をしないと分かりにくいなという感じがした。

先に違いあることについて説明 + 各メソッドではこれは破壊的ですとか書いていくスタイル

[azu]

Array-likeという用語 使わなくても普通にでてくるから、意味は理解できないと駄目かなー

[azu]

コラム的な枠でもいいかなーと思ってきた

[azu]

修正は別途Issueを
https://asciidwango.github.io/js-primer/basic/array/