Javaのジェネリクスは「まがい物」ではない - kmizuの日記
先日、自分が書いた kmizu.hatenablog.com に対する反応として、「Javaのようなまがい物のジェネリクスと比較するのは適切でない」「Javaのジェネリクスと比較するのは適切でない」（おそらくC#や(C++等（2017/09/24追記）)の言語と比較して）といった コメントをいくつか見かけました（はてなブックマークコメントやツイッターなどで）。しかし、ここでは、そのような言説こそが適切でない、ということを言いたいです。なお、methane氏との 対話については既に終わったものなので、それとは関係ありません。 そもそも、Javaジェネリクスは、静的型付き関数型言語で既に一般的であったパラメータ多相をJavaに追加する目的で導入されました（C++テンプレートのようなものをJavaに追加するためだと思っている人がいるかもしれませんが、それは実態にあっていません）。実際、Java
インタフェースと型クラス、どちらでもできること・どちらかでしかできないこと - Qiita
最近にわかに 型クラス が盛り上がっているようです。しかし、型クラスはインタフェースに似たものだという意見もあればまったく別のものだという意見もあり、混乱する人が多いのではないかと思います。 そのような混乱を招く理由は、 インタフェースと型クラスはどちらも抽象化を実現するためのもの であり、 インタフェースでも型クラスでもできること インタフェースでしかできないこと 型クラスでしかできないこと があるからです。 1 に着目した人は似ていると語り、 2 や 3 に着目した人はまったく違うものだと言います。 本投稿では、 Java / Kotlin のインタフェース、 Haskell の型クラス、 Swift のプロトコルを比較し、上記の 3 点を整理します。 Swift のプロトコルを加えるのは、 Swift のプロトコルがインタフェースと型クラスの両方の性質を備えたものなので、比較対象とし
型クラスはインターフェースとどう違うのか | POSTD
(注：2017/02/27、いただいたフィードバックを元に翻訳を修正いたしました。) Haskellの型クラスは、Haskellを学び始めたばかりの多くの人にとっては難しい概念です。たいていの言語はこれを表すことが全くできませんし、それに近い概念も持っていません。多くのオブジェクト指向型の言語にとっては、利用可能なものの中では Interface が最も近い言語要素でしょう。Rubyの modules は似たような役割を持っています。しかし、この概念は両方とも、名前の多重定義と一種のポリモーフィズムをアドレスするので、型クラスが提供するパワーの一部を欠いています。 この記事は、型クラスに興味を持っている人向けです。Haskellや関数型プログラミングの予備知識は必要ありません。JavaやC言語のような静的な型付き言語に慣れていれば、役に立つでしょう。 型クラスについての概要/要約 型クラス
「Javaにおけるnull。これまでとこれから」という発表をしてきた | さにあらず
JJUG CCC 2015 Spring（4 月 11 日開催） で発表をしてきました。 一コマ目であり、エントランスから一番近い入り易い場所だったせいもあるとは思いますが立ち見が出る程の盛況ぶりでした。発表を聞いて下さった皆様、本当にありがとうございます。 発表資料はこちらです。 Past & Future of null in Java 発表者がどういう風に考えてコンテンツを作り、どういう準備をしているのか、というのは余り共有されていないように思います このエントリでは僕がどの様に事前準備を行い、当日はどんな風に考えながら発表していたのか記録しておきます。 事前準備 内容の決め方 まず、50 分では前提条件の多くなる話はできませんので、凡そ言語仕様かライブラリの話をするのが妥当でしょうとアタリを付けます。 恐らくビギナー向けを標榜しつつも、設計方法論などメタモデルについて話をするの
Java 8のOptionalをGroovyから超簡潔に使用する - uehaj's blog
結論 Java8のOptionalは超すっきり扱えるよ、そう、Groovyならね。 Optionalって何? Java 8で導入される新規クラスの一つ、java.util.Optionalは、メソッドの実行結果で成功する場合と失敗する場合があるときに、その返り値で成功と失敗を表現するためのものです。 Opitonalは単一要素を保持するコンテナ型。成功した場合は返り値をコンテナで保持させたものを返す。(成功時の返り値をラッピングする) 「失敗」は固定のシングルトン(Optional.empty())として扱う まあ、それだけの話といえばそれだけなのですが、効果は、 失敗のある可能性のあるメソッドと無いメソッドをコメントではなくプログラムの一部として明示し、両者の違いをコーディング上も区別する 失敗のある可能性のあるメソッドと無い混在・混同することのないようにコンパイル時チェックをできるよう
Java8でのプログラムの構造を変えるOptional、ただしモナドではない - きしだのHatena
※ 5/29 3:23 追記：なんかモナドになったかも。最下部参照 さて、Java8での拡張をいろいろ見てきたわけですが、ではアプリケーションプログラムでFunctionを受け取るメソッドをがんがん定義するかというとそういうことはあまりなく、フレームワーク的な部分で数個定義する感じになると思います。もちろん数個でも効果はでかいのですが。 また、おそらくStreamを受け取ったり返したりするメソッドを定義することは、めったにないのではないかと思います。 Mapでの拡張も、メソッド内部での処理記述がかわる話で、メソッドの引数や戻り値はMapのまま変わりありません。 Javaでのプログラムの構造というのは、メソッドの引数や戻り値の型がなんであるかで決まると言うことができます。その意味では、lambdaやStreamというのは処理の記述は変わるけどプログラムの構造は変わらないとなります。 けれども
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java is Unsound: The Industry Perspective | HackerNoon
https://dl.acm.org/citation.cfm?id=2984004
Java 10でぼくたちの生活はどう変わるの？
Javaプログラミング入門