アカウント名:
パスワード:
動的型言語でコーディングする際、関数、メソッドの戻り値で、
エラー時 : false(bool)を返す 正常時 : 値を返す(array等)を返す
なんて書き方を良くします。
同じ様な事を、静的型言語でやろうとすると、結構メンドイ。型付けが無いって事は、逆にメリットもあると思うんだけどな。
静的、動的共に経験あるから、双方の気持ちも良くわかるし、実際、動的型言語を初めてやった時は、違和感あった。特に、コンパイル時のチェックが入らない点。良く使う部分で、表現力の幅が広がるって点で、動的型言語が好きです。
今となっては、静的型言語は、コンビニにスーツで行く様な感覚を受ける。出来れば、Tシャツで、さっと行きたい・・・・
C# なら Nullable<T> 型 [microsoft.com]でどうぞ。
int? i;i = 1;i = null;
こんな使い方ができる。
普通は型Tに対してSome(T)とNoneのいずれかしかならない型Option(T)を使ってパターンマッチします。何も考えずにエラーコードとしてfalseや-1を返せば呼び出し元が正しくエラーを処理しているか明らかでない一方、パターンマッチならNoneを見逃せばコンパイルが通りません。Tシャツで出て行くつもりが、裸で出て行くなんて事にならないわけです。
Maybeモナドの考え方だ。あんたHaskell使いだな…(ニヤリ
ややオフトピ気味ではありますが。
もし、例外を取り扱うことのできる言語を使っているのであれば、エラー時には例外をご利用になられるほうがよろしいかと思います。関数・メソッドの役割(挙げられた例のような場合であれば、その関数は「配列を返す関数」と限定できる)もはっきりしますし、プログラムの流れも把握しやすくなりますから、可能であれば是非。
# 慣れると、例外処理なしでコードを書くのは「右にしか曲がっちゃいけない」という制約付きで# 家の左側に隣接するコンビニまで歩かされるような面倒さ感じるようになるかもしれません。# できればfinallyまでサポートされていると楽ですよねぇ…(とPHPに愚痴ってみる。笑)。
5.5で実装されたよ >finally
な、なんですと!これは機をみてPHP環境のバージョンアップを進言せねば…。
# とまで言うほど必須じゃないけど、やっぱりあれば便利だよね。# マジメに5.4からの環境更新が可能かどうかチェックします(とはいえ次のプロジェクトからだよなぁ…)。# 情報、感謝です > #2335520 [srad.jp]さん
元ACではありませんが、例外というのは評価の順序が変わり得る機構 (遅延評価とか、継続とか) といまいち相性が良くないんですよね。
# まあ、継続渡しを徹底するなら「失敗継続を渡す」が例外の処理の指定と言えるんで、そういうのを含めて例外を使おう、# というならまっとうな主張ですが。## そう考えると相性が悪いのは例外ではなく、例外ハンドラが動的束縛であることかもしれない。
同じ様な事を、静的型言語でやろうとすると、結構メンドイ。
そのとおり。だから静的型付けの言語では、同じ機能を実現するのにそのような設計はしない。Haskell のような高度な型システムを持つ言語では、そのような返り値は Maybe Bool というように表す。だから、実際には面倒なことは何もない。静的型付けで高度な表現力がありながら、型チェックが利くといういいとこどりの言語が実際に存在する。そうなると、高度な表現力があっても、型チェックが利かない言語を選択する理由はない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
表現力の幅 (スコア:0)
動的型言語でコーディングする際、関数、メソッドの戻り値で、
エラー時 : false(bool)を返す
正常時 : 値を返す(array等)を返す
なんて書き方を良くします。
同じ様な事を、静的型言語でやろうとすると、結構メンドイ。
型付けが無いって事は、逆にメリットもあると思うんだけどな。
静的、動的共に経験あるから、双方の気持ちも良くわかるし、実際、動的型言語を初めてやった時は、違和感あった。
特に、コンパイル時のチェックが入らない点。良く使う部分で、表現力の幅が広がるって点で、動的型言語が好きです。
今となっては、静的型言語は、コンビニにスーツで行く様な感覚を受ける。
出来れば、Tシャツで、さっと行きたい・・・・
Re:表現力の幅 (スコア:1)
C# なら Nullable<T> 型 [microsoft.com]でどうぞ。
int? i;
i = 1;
i = null;
こんな使い方ができる。
Re: (スコア:0)
普通は型Tに対してSome(T)とNoneのいずれかしかならない型Option(T)を使ってパターンマッチします。
何も考えずにエラーコードとしてfalseや-1を返せば呼び出し元が正しくエラーを処理しているか明らかでない一方、パターンマッチならNoneを見逃せばコンパイルが通りません。
Tシャツで出て行くつもりが、裸で出て行くなんて事にならないわけです。
Re:表現力の幅 (スコア:2)
Maybeモナドの考え方だ。
あんたHaskell使いだな…(ニヤリ
Re: (スコア:0)
ややオフトピ気味ではありますが。
もし、例外を取り扱うことのできる言語を使っているのであれば、エラー時には例外をご利用になられるほうがよろしいかと思います。
関数・メソッドの役割(挙げられた例のような場合であれば、その関数は「配列を返す関数」と限定できる)もはっきりしますし、プログラムの流れも把握しやすくなりますから、可能であれば是非。
# 慣れると、例外処理なしでコードを書くのは「右にしか曲がっちゃいけない」という制約付きで
# 家の左側に隣接するコンビニまで歩かされるような面倒さ感じるようになるかもしれません。
# できればfinallyまでサポートされていると楽ですよねぇ…(とPHPに愚痴ってみる。笑)。
Re: (スコア:0)
5.5で実装されたよ >finally
Re: (スコア:0)
な、なんですと!
これは機をみてPHP環境のバージョンアップを進言せねば…。
# とまで言うほど必須じゃないけど、やっぱりあれば便利だよね。
# マジメに5.4からの環境更新が可能かどうかチェックします(とはいえ次のプロジェクトからだよなぁ…)。
# 情報、感謝です > #2335520 [srad.jp]さん
Re: (スコア:0)
元ACではありませんが、例外というのは評価の順序が変わり得る機構 (遅延評価とか、継続とか) といまいち相性が良くないんですよね。
# まあ、継続渡しを徹底するなら「失敗継続を渡す」が例外の処理の指定と言えるんで、そういうのを含めて例外を使おう、
# というならまっとうな主張ですが。
## そう考えると相性が悪いのは例外ではなく、例外ハンドラが動的束縛であることかもしれない。
Re: (スコア:0)
同じ様な事を、静的型言語でやろうとすると、結構メンドイ。
そのとおり。だから静的型付けの言語では、同じ機能を実現するのにそのような設計はしない。
Haskell のような高度な型システムを持つ言語では、そのような返り値は Maybe Bool というように表す。
だから、実際には面倒なことは何もない。
静的型付けで高度な表現力がありながら、型チェックが利くといういいとこどりの言語が実際に存在する。
そうなると、高度な表現力があっても、型チェックが利かない言語を選択する理由はない。