JavaScript の undefined と null を完全に理解する
JavaScript で頻出する undefined と null について語ります。 言語仕様上の違い JavaScript (ECMAScript) において、仕様上 undefined と null は当然ながら明確に区別されています。いくつか言語仕様上の扱いについて挙げてみます。 比較 厳密な比較演算子 === において undefined と null は区別されます。ゆるい比較演算子 == においては両者は区別されません（仕様 7.2.14）。 console.log(undefined === null); // false console.log(undefined == null); // true 他の falsy な値（false とみなされる値）との比較は、ゆるい比較演算子であっても区別されます（仕様 同上）。 console.log(undefined == fa
Goのヌル安全について
「ヌル参照の考案は１０億ドル単位の過ち」と語ったホーア氏（Goの並列処理モデルCSPの考案者でもあります）。そしてモダンな言語処理系は「ヌル安全」を持つのが流行です。しかし、Goには完全な「ヌル安全」の仕組みを持ちません。 Goのメモリ安全機能 もちろんGoは完全なヌル安全とは言えないまでもヌルポ参照対策や不正なメモリ参照を防ぐいくつか考慮した仕組みや慣習を持っています。 ポインタの算術移動を許さない言語仕様 確保するメモリは全てゼロ値で初期化済み エラーがnilなら有効な値を返すという慣習 必須のエラーチェックがヌルチェックを兼ねている これらによりGoは完全に「メモリ安全」であり、「ヌル安全まであと一歩」までの仕組みを持っています。それでもヌルポ参照は「ランタイムパニック」という形で現れます。 ランタイムパニック Goでは「ランタイムパニック=コードの不備の通知」です。 多くのコードの
もういい加減「nullチェックをしたら安全」とかわけのわからないことを言うのはやめよう - Qiita
（僕の主観で）クソな記事をたまたま読んでしまってもにょったので愚痴。 Safe Harbor Statement 以下の事項は個人の見解であり所属する組織の公式見解ではありませんし、明日になったら違うことを思っているかもしれませんがそういう類のものです。 某所で危険と言われていたコード public void hogeMethod(Hoge hoge) { //hogeを使った処理 hoge.doSomething(); return; } 安全な理由: NullPointerExceptionが発生しない 僕がいいたかったこと それ、NPEを握りつぶしているだけですから！！！！！！！ (とくにJavaの世界においては)非検査例外というのはコーディングバグを示してくれるものですから、へんなnullチェックをいれるのではなく、積極的にNPEを発生させていきましょう。 こういうわけのわからない
失敗を表現する手法としてNullObjectパターンが不適切でEitherが適切だと思う理由 - Qiita
真面目な気分出して書いていたらすごい長くて堅苦しくてもったいぶった感じになってしまった... この記事の9割は壮大な前置きですw なにこれ 失敗の表現としてNullObjectパターン（以下楽なので勝手にNOPとします）を使うべきか議論をした際に論理立てて話せなかったので、 持論整理をしてついでにこの場を借りて晒してみようと言う記事です。 全ての状況において必ずEitherだ！と言うよりは、議論になったら僕はこう考えてますって言うためのポエムです。 DDD的な考えも少し この記事は実装都合のみに閉じていますが、DDD的な観点からも考えてみたことがあるのでこんな記事も書いてみました。 先に結論 前置きではない1割の部分だけ先出します。 それで「あ、そうか」とか「は？」とか思える人は以下の長大な前置きは不要ですw NOPは成功と失敗を区別しようとすると破綻する、けど区別したい事が珍しくない。
C#でのnull参照問題への取り組み ― null参照問題（後編）
最近のC#ではnullの存在が大きな問題となっている。前回（前編）で説明したnullの事情を踏まえ、今回（後編）は、将来のC#がnullをどう取り扱っていくのかを見ていく。 ← 前回 連載 INDEX 次回 → 前編では、nullが存在する理由や、nullがあることで起こっている問題などについて説明してきた。 後編では、C#が具体的にどう課題に取り組んでいくかについて見ていこう。C# 7よりも先の話でまだ仕様は固まっていないが、現状での仮実装や、検討として挙がっている項目について説明していく。 無効な値の表現 ただし、「具体的にどう取り組んでいくか」の話の前に、「型を使ったnullの許容／拒否の区別」とは別軸で「無効な値を表現するのにnull（0初期化）が適切かどうか」という問題もある。まずはこちらについて話しておこう。 型情報の紛失 nullは、どんな型だろうが一律に0埋めすることで、最
null安全はいいぞ。だって、型安全はいいぞ。 - Qiita
はじめに ここ数日、null安全についてバズってますね！ null安全でない言語は、もはやレガシー言語だ http://qiita.com/koher/items/e4835bd429b88809ab33 そういや先週はt-wadaさんのスライドもバズりましたね。 PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 https://speakerdeck.com/twada/php-conference-2016 これらの記事、実は同じ話してるなぁ🤔と思ったので、まとめてみました。 ※なお、この記事はコード改善 meetup #2 http://kaizen.connpass.com/event/42118/ での同名の発表を、文章形式でリライトしたものです。 スライド版(Speaker Deck)はこちら。 nul
コンパイラのリミッタが外れつつある今、null安全は必須なのかもしれない - Qiita
三行で頼む コンパイラが斜め上の最適化をするようになったからnull安全ないと怖いよね 一行で終わっちゃった。 本文 最近、ツイッターを見ていると、プログラマの間でnull安全という言葉がバズっていますね。私も次のようなエントリを楽しく眺めていた訳です： null安全でない言語は、もはやレガシー言語だ null安全はいいぞ。だって、型安全はいいぞ。 null安全を誤解している人達へのメッセージ さてそんな中、少しだけ私の心に留まったエントリがこれです： null安全な言語は、本当にゼロコストか これを読んで、私がまず直感的に思ったのは、むしろもはやnull安全のない言語はダメかもしれないということでした。こう書くと、このエントリの内容を否定してると誤解されるかもしれませんが、全くそんなことはありません。このエントリの筆者さんもnull安全の有用性を否定しているわけではないですし、私も古いタ
null安全を誤解している人達へのメッセージ - Qiita
先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃんとやらないと、コンパイルが通らないからです。
null安全でない言語は、もはやレガシー言語だ - Qiita
これらは、表中の「リプレース対象言語」に挙げたように、多くのメジャー言語に対する代替手段でもあります。 Java の代わりには Kotlin や Ceylon が、 JavaScript には TypeScript や Flow が、 Objective-C には Swift が、そして PHP には Hack があります。 Python は自身に null 安全 を取り込みました。 Crystal は直接 Ruby と連携して使えるわけではありませんが、 Ruby 風の null 安全 な言語です。 Rust は C++ の代替を目指して開発され、 Firefox の一部で C++ のコードを置き換えるのに使われています [^100] 。 null が引き起こしてきた数々の問題を考えると、僕は、 null 安全 は GC （やその他の安全なメモリ管理手法）に匹敵するプログラミング言語の進
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
