Go言語(Golang) はまりどころと解決策
Go の言語仕様はシンプルで他の言語に比べてはまりどころが少なくて学習コストが小さめな言語のように思います。しかし、それでもはまるところがないわけではないので、自分がはまって時間を無駄にしてしまったことを書き留めておきます。 念の為誤解のないように追記しておくと、この文書の目的は Go を批判することではなく Go が Go であるがゆえに C++/Java/Python など利用者が Go を使い始めるときに困惑あるいは誤解するであろうポイントをまとめておくことで初めて Go を触る人がスムーズに Go を使い始められるようにすることです。私個人は Go はバランスがとれた良い言語でだと思いますし、気に入っています。 目次 interface と nil (Go の interface は単なる参照ではない) 文献 メソッド内でレシーバ(this, self)が nil でないことをチェ
re:僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - ぐるぐる～
元ネタ: 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記 OOPの文脈で見ると、元の記事が言っていることもわからなくはないのですが、対象が広すぎていろいろと不正確になってしまっているので、ちょっとまとめてみます。 元の記事が対象にしているのは、Maybe / Optional / Nullableの3つです。 対応する型を持つ言語を見てみると、下記のようになります。 Maybe(Haskell) Optional(Swift/Java) Nullable(C#) これらは、「値がないこと」を表すもの、という見方では同じですが、それぞれ異なる価値観の元に作られています。 Maybe/OptionalとNullable これらはすべて型パラメータを取ります*1。 しかし、この中でNullableだけは型パラメータに
値渡しと参照渡し (と参照の値渡し) - ぐるぐる～
値渡しと参照渡しは、分かってしまえば何も難しいところはないんだけど、分かるまでにちょっとした壁があるというかなんとうか・・・ てことでちょっとまとめておきますねー 値渡し (call-by-value) と参照渡し (call-by-reference) の違い 値渡しと参照渡しの違いは、「呼出し元の値自体を変更できるかどうか」と説明されることが多い。 しかし、例えば Java ではミュータブルなオブジェクト *1 を渡した場合、呼出し元の値自体を変更できるという勘違いをする可能性があるため、この説明はあまり好ましくない。 そのため、参照渡しを「呼出し元の別名を渡している」と覚えるのが分かりやすいと思う。 値渡しは「何かの値をコピーして渡している」と覚える*2。 Java の場合 Java には値渡ししか存在しないが、「参照型」のためにややこしく感じる。 参照型は参照渡しとは無関係で、C
C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる～
Java8 から追加されるインターフェイスの default 実装ですが、C# の拡張メソッドに似てますよね。 実際、このどちらも「シンインターフェイス」を定義するだけで「リッチインターフェイス」が手に入ります。 しかし、C# の拡張メソッドと Java のインターフェイスの default 実装には、それぞれの利点と欠点があります。 拡張メソッドの利点 拡張メソッドの利点は、インターフェイスの実装者だけでなく、 インターフェイスの使用者に対してもインターフェイスの拡張が開かれている点です。 既存の型ですら、後付けでメソッドを追加することができるということです。 using System; public static class StringExtension { // インターフェイスでなくても、どんな型に対しても拡張可能 public static int ToInt(this str
Java総称型のワイルドカードを上手に使いこなすための勘所 - 達人プログラマーを目指して
Java5以降では総称型（generics）がJava言語に導入されています。総称型自体は、最近の静的な型付けのプログラミング言語で珍しいことではなく、現在の最新版では.NETのC#やVisual Basicにも導入されています。一般的には総称型をサポートするクラスライブラリを自分で正しく定義することは非常にスキルがいるが、事前に定義されたクラスを使うだけであれば、それほど難しくないとされています。しかし、Java言語の総称型は本エントリで説明するように特殊なところがあり、単に利用するだけでも他の言語に比べて遥かに難しいところがあるというのも事実です。特に総称型をパラメータ化する際に指定するワイルドカード型（List<? extends Serializable>など)の意味を正しく理解して使いこなすことは簡単なことではありません。その結果、昔のJDK1.4までのように型パラメーターのない
業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
【Visual Studio Code】1.0 GAリリース予定日、決定！ - 好きな技術を好きと言える幸せ - AYA TOKURA BLOG - Site Home - MSDN Blogs
Microsoft Developer Blogs Get the latest information, insights, and news from Microsoft. AI agents are quickly moving from experiments to production‑critical components of modern applications. But while many teams know how to build agents, far fewer are confident they’re hosting them on the right foundation. Most organizations start by deploying agents the same way... We're shipping two major capa
Gushwell's C# Programming Page - C#デザインパターン
ここに掲載したコードは、『増補改訂版Java言語で学ぶデザインパターン入門 / 結城 浩(著)』に掲載されているサンプルコードをC#に移植したものです。 ブログ「Gushwell's C# Dev Notes」に掲載していましたが、多くのブログ記事の中に埋もれてしまっているので、こちらに引っ越すことにしました。なお、ブログに掲載したソースは、原書のソースコードにできるだけ忠実にC#に移植することを心がけましたが、こちらに引っ越す際に、C#2.0, C#3.0の練習も兼ね、すべてのソースに見直しをかけています。どうでもいいところで、LINQを使ったり、ジェネリックスを使ったりしていますが、そこは笑って許してください。 ただ、デザインパターンの本質部分は、C#の特徴を出しつつ、原書の設計を踏襲しているつもりです。 C#のソースファイル（プロジェクトファイル）もダウンロードできるようにしています
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
