Rustでクラスを表すと
本稿の目的 Rustに存在しない「クラス」をRustの既存機能の組み合わせとして表現することで、一般的なOOP言語とRustのデータ表現に対する考え方の違いと、各概念がどのように対応しているかを理解しやすくすることが主な目的です。 主な想定言語 C++, Java, JavaScript, Rubyのクラスを主に想定しています。 方針 サブタイピング Rustにはごく限定的なサブタイピングしかないため、クラスのサブタイピングに相当する変換は明示的に .as_ref() / .as_mut() として表現します。 Deref / DerefMut を使うことで、このような振る舞いを部分的に再現できる場合もあります。ただし、この用途でDeref / DerefMutを使うのは推奨されていません。 カプセル化 一般的なOOP言語では継承関係に基づいたアクセス制御 (protectedなど) が行
2022年、Rustの未来を探る旅 (1) はじめに
※大風呂敷を広げてやる気だけ表明する記事です。まだ中身はない。 はじめに Rustは2009年頃に誕生し、2015年に正式リリースされたプログラミング言語です。その革新性はおよそ以下のように集約されます。 shared XOR mutable とそれに付随する発明 (所有権、ライフタイム) により、ミュータブル参照が正しく扱えるようになった (責任分界点が明確になった) こと。 上記のアイデアにより、高パフォーマンス・低フットプリントが求められるアプリケーションやOS・GC・アロケーターのない環境で動く必要のあるアプリケーションをより安全に書けるようになったこと。 プログラマーが安全に・快適にプログラムを書くための既知の優れた道具 (パッケージマネージャーなど) を計画的に取り入れ、伝統的なプログラミング言語が抱えがちな問題を広範に解決したこと。 これらの革新性から、これまでC/C++が担
JavaScriptの非同期処理をじっくり理解する (1) 実行モデルとタスクキュー
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 入門記事へのリンク プロミスの使用 - JavaScript | MDN Promise, async/await (現代の JavaScript チュートリアル) JSの初心者にPromiseとasync/awaitの使い方
Temporal Dead Zone と採用されなかった他の候補について
Temporal Dead Zone とは ECMAScript 2015で採用された let/const のスコーピングの仕様をTemporal Dead Zoneと呼びます。 const x = "outer"; { const f = () => x; // console.log(f()); // => Error const x = "inner"; console.log(f()); // => "inner" } 4つの方式 Temporal Dead Zone という名前は、ブロックスコープ変数の挙動を決める際の4つの候補の名前に由来しているようです。 これはECMAScript 4が放棄されて間もない2008年10月のes-discussのログ[1]に言及があります。 A1. Lexical dead zone. References textually prior to
CORSの仕様はなぜ複雑なのか
Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基本となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別
公式ドキュメントの読み方
「公式ドキュメントを読め」というのが急に話題になっていたので自分なりに整理してみました。 注意: そんなに真面目に推敲していません。フィーリングで書いているので実態に即してない部分もあるかも…… 公式ドキュメントとは何か あなたが使おうとしている道具 (ライブラリ、フレームワーク、プログラミング言語、ミドルウェア、コマンドラインツール、etc.)[1] は必ず誰かによって作られています。ある程度成熟した道具であれば通常、その作った人・組織自身によって公開されているドキュメントがあるはずです。これが公式ドキュメントです。 公式ドキュメントは、OSSにおいてはソースコードと双璧をなす最も信頼できる資料のひとつです。ソースコードが非公開の場合は通常、公式ドキュメントが最も信頼できる資料でしょう。 (以降はOSSを主に想定して説明します) たとえば…… Python のソースコードはGitHub上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
