想定環境

• macOS
• rust (v1.69.x)
• VSCode

rusty_v8
https://github.com/denoland/rusty_v8
https://docs.rs/v8/0.73.0/v8/

環境構築

rust, cargoのセットアップができていない場合は先にこちらを
https://www.rust-lang.org/learn/get-started

VSCodeにrust-analyzerを入れよう。
https://marketplace.visualstudio.com/items?itemName=rust-lang.rust-analyzer

Rust (cargo) オンボーディング

PJを作る

cargoでサクッと

cargo new v8_sanmple
cd v8_sanmple

試しに動かしてみる

cargoでサクッと

cargo run

"Hello, world"が出力されたらOK

簡単なディレクトリの説明

• src/main.rs
  rustのソースコード。モジュールを作る際はsrcに作っていく。今回はmain.rsだけ使っておけばOK.
• target
  ビルドしたりすると成果物がここに生成される。触ることないので気にしなくてOK
• Cargo.toml
  package.jsonみたいなもん。必要なパッケージとかがあればdependenciesを追加したいりする。
• Cargo.lock
  ロックファイル。触らないので気にしなくてOK

簡単にrusty_v8を使う

dependenciesにrusty_v8を追加する

Cargo.toml をいじる

[package]
name = "simple_use"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
v8 = "0.73.0" # ここ

後は使いたいところでuseするだけ。
試しにmain.rsでuseしてみる。

use v8;

fn main() {
    println!("Hello, world!");
}

宣言しただけで、特に何もしてないが、試しに動かしてみるとインストールが始まると思う(時間かかる)

cargo run

軽くスクラップを書くつもりがなんと手元のPCでビルドができない事態に。
また気が向いたら書く

https://twitter.com/paina/status/1674384101368033281?s=20

https://twitter.com/ubugeeei/status/1656473287793471488?s=20

ちなみにあれは若干誤解があるんですけど、setupの結果はコンパイラによってOptions APIのあの形になるわけではないです。
setup自体はコンパイラの力を必要としません(別のAPIってだけです)
script setupも、いつものsetupの形になると言うだけで、OptionsAPIのあの形にはならない

setupに定義されたそれぞれのステート・関数は普通にレキシカルな環境で参照しあっていて、templateにバインドされた値だけコンポーネントインスタンスのproxyを返して参照される感じになっていますね、(しかしここでもthisという単語は登場すらせず、render関数に引数としてctx (インスタンスのproxy) を渡している)
さらにいうと、setupのreturnとしてrender関数を定義する場合にはproxyすら介さず普通にクロージャをキャプチャしている

むしろ、Vue3以降のコードではこっちがベースになっていて、追加でOptionsAPI「も」使えるような実装になっている。

VueのコンパイラというのはtemplateとSFC(script setupやその周辺のマクロ)を実装するものなので、CompositionAPIをOptionsAPIに変換するものでは無い

これらのマージはコンパイラではなくランタイムが行っている (実際にはマージすらされておらず、それぞれ別の領域に存在していて インスタンスのproxyでそれぞれを見に行っている)

https://twitter.com/ubugeeei/status/1667131741507821568?s=20

サカバンバスピス、サカバンバ(村の名前) + アスピス (盾)らしいので、「アスピ」の部分ってみんな大好きaspidaのaspiの部分らしい

https://twitter.com/ubugeeei/status/1669847015742902273?s=20

https://en.wikipedia.org/wiki/Duff%27s_device

https://hotnews8.net/programming/tricky-code/statement03

resource: https://typelevel.org/cats-effect/docs/std/resource

TODO: 持論を書く

https://twitter.com/public_ai000ya/status/1665423170466385920?s=20

https://github.com/Ubugeeei/vue-hooks

https://twitter.com/Atinux/status/1666739314707898370?s=20

https://github.com/unjs/h3

「組織内の仕事やお金を管理する」と言って意味があるadminister、これはad(方向 (to とかに近い)) + minister(仕える)で方向を仕える(管理する)イメージ。

ministerはministerで、minus + erになっていて、これは minus (大きな存在に仕える小さい) er (人)という語源らしい。

みんな大好きpingコマンド。
これは「Packet INternet Groper」の略らしいの略らしい。

A utility, commonly known as PING, which is used to query another computer on a TCP-IP network in order to check that there is a connection to it. The user of this utility executes it with the name of the computer or its IP address, and it then sends out a set of messages which ask the remote computer to reply and produce a short report on whether the connection was achieved. Most operating systems contain a simple PING utility; there are also many commercial and shareware versions available. It is sometimes referred to as the Packet INternet Gopher.

https://www.oxfordreference.com/display/10.1093/oi/authority.20110803100300429;jsessionid=DB2CD3A7B8F54EFAC03516334AB33A9F

Groperは手探りして見つけるという意味の Grope + er.

調べてると、他の意味として「女性に強引に痴漢行為をする」という意味もあるらしくてあんまり積極的には使いたくないなと思った。使う際は文脈に気をつけたい。

https://qiita.com/aobat/items/e38fb165c58e0daa1e51

https://twitter.com/ubugeeei/status/1656064433893019648?s=20

reactiveの存在意義というか、reactiveというものがVueの基本ではあるのだよな
reactivity関連のAPIのうち、最も低級なものであるはず (使うか使わんかは別として)
アセンブリというわかりやすい言語があるのにバイナリってなんで存在してるの？みたいなイメージ
https://twitter.com/ubugeeei/status/1668808274622439424?s=20

reactiveオブジェクトの、オブジェクトをまるっと置き換えることが出来ないという制約、shallowRefのまるっと置き換えることしか出来ないと言う制約は上手く使い分けたい感じがある
この制約に意味を乗せる事って結構出来ると思うんだよねぇ
手動トリガーは禁止という前提でね
https://twitter.com/ubugeeei/status/1668795045057789952?s=20

ステートとして扱うオブジェクトにリアクティビティを実装するぞ！ -> うーむ。まぁCompositionだし分解できるような形式にしよう -> せや、リアクティブオブジェクトへのreferenceを提供するようなAPIにすればええんや

という流れだと勝手に認識していて、
ステートをどういう区切りにするかは開発者の裁量だし、ひとつのステートにまとめたくなるようなケースは往々にしてあるし、そういう時に使うと認識している (例えばフォームとかね)
https://twitter.com/ubugeeei/status/1668814589704941569?s=20

https://techblog.paild.co.jp/entry/2023/06/12/170637

答えは、nodeのランタイム上 (JSの範囲内にJSのオブジェクトとして持っている)

コードを読む。

もちろんlib/httpから

https://github.com/nodejs/node/blob/main/lib/http.js

createServerの実装

[node/http.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/http.js#L63)

_http_server.jsのServerを呼び出している (thisでcallしてることに注意)

[node/_http_server.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_server.js#L510)

こいつはnet.jsのServerを呼び出している

[node/net.js at main · nodejs/node](https://github.com/nodejs/node/blob/main/lib/net.js#L1664)

ここで、EventEmitterを呼び出していることに注意。

EventEmitterを呼び出すことでthisに対してonとemitという関数を実装している。

_http_server.jsに戻って、net.Server呼び出し後の処理を見てみると、ここで this.on('request', requestListener); としている。requestListener　というのがユーザー定義のリスナー (createServerに渡すやつ)

requestというイベントに対してこのハンドラを呼び出すように設定しているよう。

[node/_http_server.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_server.js#LL531C1-L531C1)

つまり、ユーザーが書いたハンドラはevent.tsで実装されている機構 (をServerインスタンス内でインスタンス化したもの)に登録されている

あとは、実際にリクエストが飛んできた時に、requestというイベントをemitしているらしい。それはここの実装。(parserOnIncomingという関数)

[node/_http_server.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_server.js#L1008)

• この辺ね

  https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_server.js#L1109

  https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_server.js#L1121

じゃあ、実際に parserOnIncoming はどのタイミングで実行されるように設定されてるの ? という話

parserのイベントに登録されてるらしい

[node/_http_server.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_server.js#LL693C3-L695C1)

初期化処理はここ

[node/_http_server.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_server.js#L650)

このイベントハンドラは

_http_common.jsのparserOnHeadersCompleteで呼ばれていて、

[node/_http_common.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_common.js#L72)

[node/_http_common.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_common.js#L119)

parserOnHeadersComplete自体はHTTPParserとやらに登録されている。

そしてなんと、こいつ、C++実装へのバインディングなのだ！！！

[node/_http_common.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/_http_common.js#LL31C33-L31C48)

やっとゴールが見えた感じ。

バインディングの実装はここらしい

lib/bootstrapってところにいる。

[node/realm.js at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/lib/internal/bootstrap/realm.js#L178)

そして、今回の場合、http_parserというモジュールに対してのバインディングなので、中身の実装はここ

[node/node_http_parser.cc at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/src/node_http_parser.cc)

きましたね〜ここから先は C++ の領域。

そして、nodejs自体、http の実装は nghttp という C++ のライブラリを使っているみたいで、socket周りのシステムコールとかはこいつが呼んでる。

[node/node_http2.h at fa1c73213f387f5e12b7133299b3f7ddef1126f1 · nodejs/node](https://github.com/nodejs/node/blob/fa1c73213f387f5e12b7133299b3f7ddef1126f1/src/node_http2.h#L9)

https://github.com/nghttp2/nghttp2

ここを見ても分かる通り、sys/socket の socket 関数を呼ぶ出す記述は nodejs リポジトリには見当たらない。

[https://github.com/search?q=repo%3Anodejs%2Fnode socket(&type=code](https://github.com/search?q=repo%3Anodejs%2Fnode%20socket(&type=code)

あとはsocket呼び出してシステムコールが発行されてOSに指令が言ってOSがNICなどのハードウェアに命令出して通信をする

まとめ

つまりまとめておくと、

• ユーザーが定義したハンドラは、lib (js実装) の Serverインスタンス内に登録されていて、それはEventEmitterの実装で成り立っている。(’request’というイベントに対してリスナを登録している。)
• nodejsのhttp実装(システムコールなどを含むC++実装)はnghttpというライブラリを使っている。
• リクエストが来た際にhttp-parser(C++実装)でリクエスト内容をパースする。
• パースが完了したタイミングで、バインディングによって事前にJS実装から登録された、parserOnHeadersComplete (js実装)が呼び出され(ここから先はjsの世界)、’request’というイベントをemitして、ユーザー定義のハンドラを実行

https://twitter.com/ubugeeei/status/1666787327375704065?s=20

論文の一人称として、「We」を使っていたら編集部に「著者が一人ならIにするべき」と指摘されたが、書き直すのが大変だったので著者に飼い猫を含めた教授がいる

Oberview

この言葉はライス大学が発祥だそう。(ヒューストンの名門)

ざっくりまとめると、

• パラダイムの長短を議論するための言葉
• 「静的型付き言語で、再コンパイルをせずに新しいデータ型や関数を追加できるようにするにはどうしたらよいか」という議論で、各パラダイムがどうか、という議論

OOP vs FP

この問題に対する OOP と FP の対比は

OOP

👍 データ型を追加するのが容易
👎 関数を追加するには既存のクラスに変更を加える必要がある

FP

👍 関数を追加するのが容易
👎 データ型を追加するには既存の関数に変更を加える必要がある

と言った感じの議論。

参考

wikipedia

発祥となったメール?

Expression ProblemにおけるOOPと関数型の対比について (Arantium Maestum)

The Expression Problem and its solutions (Eli Bendersky's website)

Expression_Problem (mrsekut-p)

https://twitter.com/i/bookmarks/all

仕事以外の思考ログを残す場所です

FiberってやつがVueでいうところのComponentInternalInstanceに当たるやつだよね (?)

https://github.com/facebook/react/blob/613e6f5fca3a7a63d115988d6312beb84d37b4db/packages/react-reconciler/src/ReactInternalTypes.js#L83

https://github.com/vuejs/core/blob/d2c3d8b70b2df6e16f053a7ac58e6b04e7b2078f/packages/runtime-core/src/component.ts#L221

教えて詳しい人

ん〜でも

There can be more than one per component.

ってあるからインスタンス的なもの一部なのか、
いややっぱりインスタンスと呼ぶのは不適切なのか

partialInstanceとか、関数のioだと考えるならpartialOutputとかっていうのが正しいんだろうか

ioっつったって、特定のコンポーネントから生成されたのメモリ空間のようなものなのでやっぱインスタンスでもいいと思うんだよなとも

https://twitter.com/ubugeeei/status/1669992549057191938?s=20

ReactのuseStateとかuseRefって値の所在はあくまでコンポーネントのインスタンス内に隠蔽されるものだと思っていて、その領域のリソースにアクセスする時にuseって言うイメージがある

一方でVueはというと、値の所在自体はユーザー側にあって、それにリアクティブを実装しているだけなので、セットアップなんだよな(？)

そしてそのセットアップを分解して合成可能な感じにしておくイメージ

Reactのuse𓏸𓏸と Vueのuse𓏸𓏸はまるで意味が違うと思っている
Vueはmixとかcomposeとかsetupの方がしっくりくる
storeとかprovide/injectが絡むもののイメージはuseなんだけど、単純にリアクティブな機能を切り出して使う時ってcomposeとかのがしっくりくる気がするんだよなぁ

https://twitter.com/ubugeeei/status/1669929136738177024?s=20
https://twitter.com/ubugeeei/status/1669927686670815232?s=20

アンパサンド (&) はかつてアルファベットの27番目の文字だった。しかし学校の生徒が「...X, Y, Z, and」と覚えると混乱するため「...X, Y, Z と andそれ自体 (...X, Y, Z and per se and)」と復唱していた。この表現が縮まって "ampersand" となった。
引用元

https://www.dictionary.com/e/ampersand/

Vueに対してReactが持つような固有の一貫性を求めるな、Vueの役割はそこじゃないので。というのが結論かな
Vueの役割は色んな一貫性に適応することだ

script seupが嫌いなら使わなければいいじゃない。他の選択肢があるんだから（そういうフレームワークなんだから）
refとreactive、混在するのが嫌ならどっちかだけ使ってればいいじゃない （そういうフレームワークなんだから）
.valueがうざくてgetter/setterが欲しいならそういうcomposableを作ればいいじゃない （そういうフレームワークなんだから）

Vueの確かたる主張は「Progressive Framework」だが
全体として、どういう一貫性を持たせるかはユーザー次第なのよ
必要になった時に用意されているということが大事なことなのであって、APIセットを眺めて一貫した主張がないと言われても…… （一貫した主張としては「必要になった時に用意されている」なので……）
その思考が良かったのか、悪かったのかは別として、主張は一貫してると思いますね。
（ここで言う良い悪いというのは単純な善し悪しではなく、「**を広めやすいか？」というのも含む）

ライブラリ/フレームワーク側が一貫性を提供するのか、選択性を提供するのかは本来トレードオフのはずなんだが、
戦略的にはライブラリ側が一貫性を提供するほうが、多くの人の興味を惹きやすく広まりやすかった、という側面はかなりあると思っています（公式が粋な一貫性を発表してたらみんな気になって勉強するし、持論で語れるので）

あと金

https://twitter.com/ubugeeei/status/1666624207143460864?s=20
https://twitter.com/ubugeeei/status/1666610881860599809?s=20
https://twitter.com/ubugeeei/status/1666592811775557632?s=20
https://twitter.com/ubugeeei/status/1666597430031421441?s=20

https://ja.wikipedia.org/wiki/LR%E6%B3%95

TODO: まとめる

https://drive.google.com/drive/folders/1k2vymbC3vUk5CTJbay4LLEdZ9HemIpZe

まず、stateは、元々「立っている状態」とか、「存在する状態」という意味から来てるらしい。

(standとかと同じ齟齬を持つのかな?)

祖語はsteh.
steh (立つ)に対して、ラテン語の完全受動態化であるtusとかがくっついてstatusになっているっぽい。

statusは立ち位置というイメージの方がしっくりくる

stateはこのstatusの上位語で、主要な特性に注目したときの物のあり方という意味がある。

じゃあなぜ「表明する」になるのか

「状態」も「表明」も共通するイメージとして「立ち位置」とか「立っていること」とかそういうものが含まれるから、動詞の場合にはその立ち位置を言語化するというニュアンスで表明、ということになっているんだろうか　(知らん　)

https://twitter.com/mitama_rs/status/1674499915693830144?s=20

http://ppl.jssst.or.jp/index.php?ss2021

https://arxiv.org/abs/1605.05274

https://logmi.jp/tech/articles/328351