静的型付け言語の潜在開発生産性は今の100倍

1 ：2013/03/03 〜 最終レス ：2013/09/02

人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。
その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。
すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。
コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。

2 ：

ここが次スレか。でJava厨はこれのどの辺に問題があると思ってんの？
このやり方でDIとして不十分だと思ってるのはなんだい？
Martin fowlerの話を読む限り問題は無さそうだが？
"依存排除側"
object := DI type1 new.
object := DI type2 typeWithValue:0.
DI type3
subclass:#type
instanceVariable:''
classVariable:''
poolDictionary:''
category:'Independency'.
"依存注入側"
DI type1: Integer.
DI type2: TypeForIntegerFactory.
DI type3: Integer.
"或いは"
delegate := Factory new.
DI type1: delegate.
"別解としてClass辞書を直接書き換えてしまう"
OldType := Type1.
System classDictionary replaceClass: #Type1 ToClass: #Integer.

3 ：

あとこれもつけとくか
初期値を設定する例
943 デフォルトの名無しさん sage 2013/03/02(土) 22:07:33.46
"注入側"
DI type1: NewDelegate withBlock:[Integer integerWithInteger:0.].
"依存排除側"
DI type1 new."Integer integerWithInteger:0.の戻り値が返される"
ね。簡単でしょ。

4 ：

>>2
関係ないスレに出てくるな
キモいよお前

5 ：

主張してる内容は真逆なのに、何故か同じ奴が立てたような気がしてならない
そんな低レベルなスレ
http://toro.2ch.net/test/read.cgi/tech/1362301911/

6 ：

リファクタリングじゃ対抗できないから
スレタイ変えただけだろ

7 ：

いいよココが隔離スレで

8 ：

前スレ

リファクタリングがしやすいのは、静的型付け言語
http://toro.2ch.net/test/read.cgi/tech/1339324882/

9 ：

>>6
次スレすでにあるぞ？ 何言ってるんだ？
リファクタリングがしやすいのは、静的型付け言語 2
http://kohada.2ch.net/test/read.cgi/prog/1362301684/
1 名前：仕様書無しさん[sage] 投稿日：2013/03/03(日) 18:08:04.99
Eclipse JDT のリファクタリング機能を探る
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/
まあ、まずこれを読みましょう。
Eclipseが凄いだけ？ 半分間違っています。
静的型付け言語が凄いから、Eclipseもここまで便利な機能を搭載できるのです。
いくらEclipseでも、動的型付け言語に同レベルの機能は搭載できません。
実際されてません。

前スレ
http://toro.2ch.net/test/read.cgi/tech/1339324882/

10 ：

>>6
ム板じゃ対抗できないから、マ板に立てたらしいぞ(>>9)

11 ：

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

12 ：

>>10
ム版に立てて欲しいのか？
それなら俺が立てるけど？

13 ：

>>12
面倒くさいからこのスレ使えよ

14 ：

埋もれてる限り無価値に等しいのはお前等のチンコが証明してるだろ
潜在とか言葉遊びは止めるといいね

15 ：

効率上げたかったら型付けなんか計算機にやらせれば良いだろ。

16 ：

ふーんいつになったら潜在能力開花すんの？
おら邪眼の力だか見してみろよ

17 ：

静的型付け言語の潜在開発生産性は今の1000罪

18 ：

関数の中に処理が
　A1
　B1
　A2
　B2
　A3
　B3
と並んでいたとする。 これを
　A1
　A2
　A3
　B1
　B2
　B3
と並び替えられるだろうか？
並び替えることが可能であれば、
このよう書き換えることが可能になる。
funcA()
funcB()
funcA {
　A1
　A2
　A3
}
funcB {
　B1
　B2
　B3
}

19 ：

行の並び替えは、出来る場合と出来ない場合がある。
実はコンパイラの最適化ではこのような行の入れ替えが行われている。
だから行の並び替えが出来るかどうかをコンピュータが判定するのは不可能ではないはずだ。
（だが動的型付け言語では不可能だろう）
これは長いコードを短い関数に分割する場合に役に立つ。

20 ：

プロコン目指してる高校生か？
そんな初歩的な話するんだったらtwitterの方が楽しいだろ

21 ：

動的型割り当てなんてモダンな最適化の基礎だろ
人間様が指定してやる時代なんてもう終わるわ

22 ：

ん？ 誰が最適化の話してるんだ？
知ってる用語並べてみた？

23 ：

むしろ言語のほうで人間様が指定しなきゃいけないことが増えてる

24 ：

ゴミムシなのに様なんて名乗れるの？

25 ：

動的言語の時代ｸﾙ━━━━━━(ﾟ∀ﾟ)━━━━━━ !?
って展開は確かにあったけど、結局性的言語持ちこたえてんじゃん。
http://www.tiobe.com/content/paperinfo/tpci/images/history_paradigm_type%20system.png
最近のブログ界隈の議論でも性的言語サイドが明らかに優勢に見えるがどうよ？
思うんだが今の時代、流れが少し良くなったからと調子に乗ると
でっかい落とし穴が待ち構えてるね。任天堂、GREE、マクドナルド以下略
よくよく心しないといけないと思うんだ(´・ω・｀)

26 ：

言っちゃ悪いけどPerl云々で始まった型についての記事なんて
最終的に自分の好みと自分の狭い世界での経験を話しをしてるばかりで
読み物としても大した参考にならんかったわ
プログラマーなら生産性のベンチマークとかして喋れよっていう

27 ：

あ、どちらの派閥もな。
動的型付け派も具体的にどういう測定方法で何倍の生産性が得られるか言わないよね
そんなの議論じゃなくて妄想乙だよ
処理速度の比較くらいだろ定量的なの

28 ：

あれな〜。
速攻で"Perl.*型"をフィードのフィルタにぶち込んだわ。
ナンセンスにも程があるし、ブクマ狙いすぎで実に草い。

29 ：

プログラムを書かない人のためのツールを書く言語がJavaやC#
プログラマ（自分自身を含む）のためのツールを書く言語がPerlやPython

30 ：

そんなずっと前から分かってることで、一人や少人数で小さ目のプログラム書くなら動的型付、多人数で大きなプログラム書くなら静的。この認識で間違いない。

31 ：

>>30
そうではなくて、
型に拘るなら静的型付け、拘らないなら動的型付け、です。

32 ：

型に拘るメリットが多いのが大規模で、
拘るメリットが少ないのが小規模ってことだよ。
なぜかというと、小規模だとコード全体が見渡せるから
型が書いていなくても、引数の型を調べるのが容易だから。
そして一人で作れるレベルだから、型やコード全体を覚えることだって可能。

33 ：

>>32
一般的には確かにそうだと思う。しかし、開発規模に関わりなく、
記号処理用の言語に見られるように、引数にリスト以外の構造体が
来ないことが普通の言語もある。この場合引数の型は意味解析に
全く役に立たない。したがってそういう読み方をしない。

34 ：

全く役に立たない。これは言い過ぎだった。変数名に意味を暗示させる
よりは、型で宣言して、変数のクラスを暗示する方がよいという考え方
もある。

35 ：

>>34で訂正している気がするがまあ無視するとしてｗ
>>33
> この場合引数の型は意味解析に 全く役に立たない。
お前、コンピュータなん？ コンピュータならどんな汚いコードでも
変な名前でも、書いたとおりに正しく動作するよ。だからなんでもいいよ。
だがな、俺らは人間だ。汚いコードだと解析に時間がかかるし、
変な名前でもそうだ。型に関してもそう。
コンピュータが正しく意味解析できるかは問題ではない。
人間が、正しく意味解析できるかのほうが重要。プログラミングの7〜8割は
既存のコードのメンテナンス。新規に書くよりも、既存のコードを読むことのほうが多い。
読む時間を減らす＝開発速度の向上。（文字数＝読む時間ではないぞ。定型句は読み飛ばすから時間には含まれない）
コードを読んで修正するのは人間だ。その人間のためにコードを書くんだ。
型が省略されていれば、その変数に何が入っているかを別の方法で確信を得なければならない。
推測ではだめだ。推測なんかするから想定外のことが起こったなんて言い訳をすることになる。
型が近くに書いていれば、すぐに確信を得られる。遠くに書いてあれば時間がかかる。
生成する箇所すべてを見なければわからないなら時間がかかるのは当たり前。
小規模だと全体を見る必要があっても時間がかからない。
だが大規模では全体を見ていたらいくら時間があっても足りない。
だから大規模開発では小さい範囲を見るだけで確証を得る手段が必要になる。それも確実な方法で。

36 ：

小規模だと、書く（タイプする）速度が重要になるが、
大規模だと、読む（理解する）速度のほうが重要なんだよね。
文字数はタイプするときには重要なことだが、
読む速度の場合、文字数はほとんど影響がない。
例えばファイル冒頭のimport文とか
どうせ読まないから、いくらあっても
読むスピードには影響しない。

37 ：

こういうコードが読みやすいって？馬鹿なの？

Map<String, Integer> bag = new HashMap<String, Integer>();
BufferedReader br = new BufferedReader(new FileReader(new File("sample.txt")));
String line = br.readLine();
while(line != null){
    for (String str : line.split(" ")) {
        Integer n = bag.get(str);
        if (n != null) {
            bag.put(str, n + 1);
        } else {
            bag.put(str, 1);
        }
    }
    line = br.readLine();
}
br.close();
for(Map.Entry<String, Integer> entry : bag.entrySet()){
    System.out.printf("%s: %s\n", entry.getKey(), entry.getValue());
}

38 ：

ユーザーがプログラマで自分でコードを直せるなら動的型
ユーザーがエンドユーザーで自分でコードを直せないなら静的型

39 ：

Map<String, Integer> bag = DefaultedMap.defaultedMap(new HashMap<String, Integer>(), 0);
LineIterator i = FileUtils.lineIterator("sample.txt");
while(i.hasNext()){
    for (String str : i.next().trim().split(" ")) {
        bag.put(str, bag.get(str)+1);
    }
}
i.close();
Commons使えば多少は楽になるけれどもサクッと書けるクロージャの類が
無いのでファイルの開け閉めの辺りが格好悪いね。ただこの問題はJavaが
タコと言うだけであって静的型とはあまり関係がないと思う。

40 ：

>>37
それは書き方が汚いだけ。

41 ：

>>39
ファイルの開け閉めなら自動クローズさせればいいよ。
http://d.hatena.ne.jp/argius/20110908/1315486185
あとGooglGuavaも使ってみるといいかな。
com.google.common.io
■Files
http://d.hatena.ne.jp/mtoyoshi/20100725/1280040233

42 ：

Groovyで静的に型指定して書くとこうなるね。
new File("sample.txt").eachLine{ String line ->
　line.trim().split(" ").each{String str -> bag.put(str, bag.get(str)+1)}
}
要するに{ -> }みたいな簡便なクロージャ記法の有無の問題であって静的動的は
あまり関係無いと思う。

43 ：

勝手に>>42付け加えるなら、記述量と読みやすさはあまり関係がない。
確かにクロージャの簡単な書き方がなければ ”書くのは” 面倒になる。
だけどその面倒な部分ってのは、あまり読まなくてもいいところ。
コメントのようなものだと思えばいい。だから読むときにの影響は少ない。
そして書くのは面倒といったが、そういうのは自動生成できることが多い。

44 ：

静的動的は関係ないけど、読みやすさには関係あるよ

45 ：

それはGroovyの静的型がオマケみたいな扱いだからじゃね？
クロージャの型だとか。

46 ：

一般的に、処理コードは読むが、定義コードは読まない。
静的型付け言語で、冗長なのは定義コードの部分であって
処理コードの量は、大差ない。

47 ：

それ、「オレは型なんて読まないぜ、だから静的型でも読みやすいぜ、キリッ」ってこと？

48 ：

型を含めた定義部分は、じっくり読むようなところじゃないってこと。
ちらっと見て、脳の短期記憶領域にさっと入れれば終わり。
もしくは必要なとき見れればいいし、IDE使ってるなら
画面外に定義があっても、簡単に見れるだろう？
時間をかけて読むのは、処理部分ってこと。

49 ：

>>45
Grooby2.0からクラスやメソッド単位で静的な型チェックを強制できるようになった
ので、クロージャの引数や返り値も静的に検証させたり推測させたり出来るよ。
個人的には静的型や動的型のどちらかではなく中間のオプショナルな型付けが好き。
その場合は言語仕様だけではなくライブラリ環境も重要で、言語は静的動的どちらで
かけるにしても、言語の主要なライブラリは特殊なもの以外はバリバリに型情報付きで
提供されている、そんな言語。
ようするに、ActionScript3さいこ〜

50 ：

つかJava由来のinterfaceは糞。
gccのsignatureやgoのinterface法式が普及すれば、
動的型付の需要が減る。
あとAutomated delegationまで使えれば、
敢えて動的型付を使う理由はない。

51 ：

>>50
>敢えて動的型付を使う理由はない。
「おれの土方仕事の範囲内では」が抜けてるぞ。

52 ：

Squeak Smalltalk で書いてみた。
| bag |
bag := Bag new.
FileStream fileNamed: 'sample.txt' do: [:file |
　　[file atEnd] whileFalse: [bag addAll: (file nextLine subStrings: ' ')]
].
^bag valuesAndCounts

53 ：

>>52
Bag使わんで書いたらどうなる？

54 ：

>>51
うん。だってGraphics処理やってたら別にDuckTyping以上の
動的型付のメリット無いもの。Message転送はたしかに便利だけど、
用途の殆んどが委譲だから自動委譲(Automated Delegation)が
有れば殆ど困んない。
ちなみにウチのソフトは1本3000万以上で売ってる。
受託と違って一本のソフトが巨大で、一本のソースが
長期間使い回されるから、依存関係を調べにくい言語は
使いづらい。
今はgoへの移行ですげぇ助かってる。

55 ：

Python3 で書いてみた
from collections import Counter
with open('sample.txt', 'r') as fp:
    bag = Counter(x for line in fp for x in line.split(' '))
    print(bag.items())

56 ：

>>52
Smalltalk最近よく見かけるようになったな。良いことだ。

57 ：

>>53
| bag |
bag := Dictionary new.
FileStream fileNamed: 'sample.txt' do: [:file |
　[file atEnd] whileFalse: [
　　(file nextLine subStrings: ' ') do: [:str |
　　　bag at: str put: (bag at: str ifAbsent: [0]) + 1
　　]
　]
].
bag associationsDo: [:assoc | Transcript showln: assoc]

58 ：

>>55
import しないで書いてみたらどうなるの？

59 ：

突然の Python3 vs Squeak Smalltalk ！

60 ：

>>58
with open('sample.txt', 'r') as fp:
    bag = {}
    for line in fp:
        for x in line.split():
            bag[x] = bag.get(x, 0) + 1
    print(bag.items())

61 ：

カウンターやBagの類のユーティリティクラスを使ってループを一つ隠さないと結局
どれも複雑になるなぁ。

62 ：

標準添付のライブラリすら使わないという制約下で書かれた>>57>>60と、
標準で付いてこないライブラリを使って書かれた>>39を比べてるのかい？

63 ：

そもそもBagなんざSmalltalkにはプレリリース版(-80 v1)から
組み込みになっているごく基本的なクラスなんだから
後続言語はせめて標準添付ライブラリくらいにはいれておけと

64 ：

>>62
>>39はマップのデフォルト値とファイル読み込みの行イテレーターという他の言語の
標準クラスにはあってjava.langには無いものを最低限Commonsで補ったもの。
標準ライブラリの機能比較ならともかく、ライブラリの機能を揃えた上で静的動的の
書き方の比較するなら>>39との比較で良いと思うよ。

65 ：

>>63
だったらSmalltalkもfileNamed:do:とか最初から入れておけと
fileNamed: fileName do: aBlock
"Avi Bryant says, ''This idiom is quite common in other languages
that make heavy use of closures (i.e. Lisp (with-file 'foo' (f) ...) and
Ruby (File.open('foo'){|f|...})). It's time Squeak had it, too.''

66 ：

だって、Smalltalk環境にFileなんてもともと無いし

67 ：

JDK標準だけだとこんな感じか。
Map<String, Integer> bag = new HashMap<String, Integer>();
BufferedReader br = new BufferedReader(new FileReader("sample.txt"));
for(String line; (line = br.readLine()) != null;){
　for(String str: line.trim().split(" ")){
　　bag.put(str, bag.containsKey(str) ? bag.get(str) + 1: 1);
　}
}
br.close();

68 ：

Groovy+Guavaで静的型に書くとこんな感じ。
Multiset<String> bag = new HashMultiset<String>()
new File("sample.txt").eachLine{String line -> bag.addAll(line.trim().tokenize(" "))}

69 ：

>>66
おいおい、どこのバカに教わったか知らんが勝手に無くすなよ！ｗ
ファイルの扱いなんざSmalltalk-80の前身のそのまた前身のSmalltalk-72から普通にあるぞ。
http://squab.no-ip.com:8080/collab/uploads/61/smalltalk-72-1977.jpg

70 ：

単にJava叩きたいだけならメッセージ転送による自動委譲が一番手っ取り早いぞ
SmalltalkやPython、 Ruby、Goなんかだと簡単なのにJavaはかったるいからな
Example >> something: aThinDevice
| thinProtocol fatProtocol |
thinProtocol := aThinDevice thinProtocol.
thinProtocol selectorA.
thinProtocol selectorB.
thinProtocol selectorC.
fatProtocol := ( FatProtocolAdapter new ) withThinProtocol: thinProtocol.
fatPrococol selectorA. "thinProtocol selectorAへ委譲"
fatPrococol selectorB. "thinProtocol selectorBへ委譲"
fatPrococol selectorC. "thinProtocol selectorCへ委譲"
fatPrococol selectorD. "FatProtocolAdapterで新たに実装"
"FatProtocolAdapterが行ってる自動委譲"
FatProtocolAdapter >> doesNotUnderstand: aMessage
　aMessage sendTo: thinProtocol.
"あとは、初期化と差分のselectorDを追加するだけ"
FatProtocolAdapter >> withThinProtocol: aThinProtocol
　thinProtocol := aThinProtocol.
FatProtocolAdapter >> selectorD
　"固有処理"

71 ：

>>69
今と同じファイルだっけ？全部シリアライズしたオブジェクトだろ？

72 ：

>.70
Javaで委譲ってかったるい？
こんなに簡単にできるんだけど。
http://blogs.wankuma.com/kazuki/archive/2008/03/23/129171.aspx

73 ：

Eclipseの機能で言語機能じゃねぇし
それに、移譲先が変化しても勝手に委譲されるわけじゃない
かったるすぎる

74 ：

統合開発環境で1000行でも2000行でもスニペットを貼り付けるのは簡単だろうよw
だったら、そのスニペットを自動生成する言語でも使えばいいんじゃね

75 ：

>>72
100種類クラスがあったら100回それするんだろ
コピペファストとか言ってたアレはどうなるんだろうなぁ

76 ：

なんかCOBOLerさんを思い出すわ

77 ：

JavaBeanswww

78 ：

コピペで簡単に出来るっつうなら言語は何でもいいっつうの

79 ：

コピペ最強さんは
プログラムを読む事など
一切想定してないんだろうな

80 ：

う〜ん、アノテーション使ったこういう委譲の方法が、無いわけでもない。
public interface Thin {
　String a();
　String b();
}
public class ThinImpl1 implements Thin {
　public String a() {return "a";}
　public String b() {return "b";}
}
public class ThinImpl1 implements Thin {
　public String a() {return "A";}
　public String b() {return "B";}
}
import lombok.Delegate;
public class Fat implements Thin{
　@Delegate private Thin thin;
　public Fat(Thin thin) {super(); this.thin = thin;}
　public String c(){　return this.a() + this.b() + "c";}
}
new Fat(new ThinImpl1()).c(); // <- "abc"
new Fat(new ThinImpl2()).c(); // <- "ABc"
表向きの見た目としてはそれなりにシンプルだと思うのだけれども、どうだろう。
(裏で何が起こっているかは突っ込んではいけない)。

81 ：

やっぱS/N比が低すぎねえか？w

82 ：

ただの慣れだろｗ

83 ：

ソースコードは静的なのに、
型定義を動的にやっても意味は無い。

84 ：

速度が全てじゃないとはいえ、速度も含めたトータルで比較したい
実際の開発だと、パフォーマンスチューニングで工数取られることもあるから

てわけで、某スレのパクリだけど、次の内容で検証して下さい
・モンテカルロ法で円周率計算して値を出力
・実行できる完全なソースコード（他者がベンチマークを検証できるように）
・サンプル数10000000のときの実行時間（実行環境も併記）

実行速度と可読性で優れた言語が優勝

85 ：

ちなみに、ライブラリの使用はありです。
可読性を上げるために、ライブラリをでっち上げるのもありです。
”ライブラリを除いた部分の” 可読性で勝負をします。

86 ：

>>80
@Delegateってなんぞ
自作の注釈なら実装貼れ
実装不可能なら意味がない

87 ：

実行速度も計るので、架空のライブラリはダメです

88 ：

>>81
どの辺が具体的にノイズだろう? 委譲自体は基本的に次の一行で簡潔していて、Thinという
インターフェイスに定義されたJavaで言うところのメソッドの扱いがthinに委譲されている。
@Delegate private Thin thin;
残りの2行はthinの値の初期化と差分の実装で、>>70の例と一緒。
何を委譲するかはThinというインターフェイスとして静的に定義しているけれども、これは
静的型だから仕方が無いねぇ。これがノイズかと問われると、インターフェイスを定義する
ことで注入する委譲先の型も静的に検証出来るし、FatがThinを実装しているというのも静的
に解るなど、静的型付けなりのメリットが出てくる。
>>83
一応>>80は型定義も静的。

89 ：

>>80
Fat自体がinterfaceなんだからFatが実装になったらいかんぞ

90 ：

>>80
そのFat classを元にして新しいclassを自動生成ってのは
おそらく可能だろうただFat自体にMember関数追加すんのは無理。
机上の空論にもならん。

91 ：

精々JNA的なトコまで実装すんのが精いっぱいだろうな
単に委譲するだけで、新しい処理を追加すんのは無理じゃね

92 ：

>>86
そういう話も出るなと思ってimport文も貼ったんだけれども。これはlombokというライブラリ。
書いたコードもちゃんとコンパイルして動くコードだよ。
http://projectlombok.org/features/index.html
裏側では委譲のためのJavaコードをアノテーションプロセッサで生成している。なので裏側は
>>74の言うところの「スニペットを自動生成」そのものなのであまり見て欲しくはないw
JavaだとDecoratorの類を書きにくいのはその通りで、言語仕様的には>>72のいう大量の
ラッパーコードを使うのがどう考えても素直で静的型検証もきっちり動く。ただこの辺りを
表面的には綺麗に取り繕うことも出来なくはないひとつの例として見てもらえると。
>>89
Fatは委譲のやり方の一例であって、インターフェイスであることは初めから意図していない。
この例だとa()とb()の実装はthinに委譲していて、Fatはc()の実装だけ持っている。

93 ：

>>92
プリプロセス的でも自動で出来るなら別にいいよ
手作業でミスするよりはるかにマシだ
変更の度に他に手が入るのは最悪だから

94 ：

移譲先と移譲元に変更があった場合も再コンパイルせにゃならんの
相変わらずメンドイな

95 ：

>>92
オーバーライドの干渉制御は手作業か。夢はあるけど不便だな。

96 ：

>>84
Python3.2.3 (1.6GHz Core i5)
実行時間: 0.80s user 0.26s system 99% cpu 1.071 total

import numpy as np
n = 10000000
x = np.random.rand(n, 2)
print(4/n * np.sum(np.sqrt(x[:,0]**2+x[:,1]**2) < 1).astype(int))

97 ：

委譲先に変更があってもインターフェイスが変わらない限り変更があった委譲先だけの
再コンパイルだし、委譲する側に変更があっても委譲先の再コンパイルは必要ないよ。
インターフェイスに変更があった場合は、そのインターフェイスを利用しているクラス
全てに影響が波及する、これは委譲しようがしまいが一緒だね。コンパイルに関しては
Javaでの既存の委譲方法に比べあまり不利はないように思う。
>>95
それはそう思う。今は干渉は静的にチェックされてコンパイル時にエラーで蹴られるので、
委譲するメソッドを列挙したインターフェイス定義を調整する必要がある。
安全と言えば安全だけど、手間はでかい。

98 ：

大規模開発向け(キリッ)

99 ：

>>97
これgenerics対応出来ないよな。
動的型付なら、委譲先のメンバー全て使える。
Javaのやり方だと委譲先のinterfaceに束縛されて、
今のinterface以外は委譲できないだろう。
新しいinterface間同士の委譲が必要になったら、
その都度class作ってSelectorDを書かなきゃならんのか？

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

CoffeeScript (266)
C#, C♯, C＃相談室 Part80 (663)
プログラム板 自治スレッド Part14 (581)
Rubyについて Part48 (890)
【TDD】テスト駆動開発【TestFirst】 (271)
Vim vs Emacs Part2 (497)
--log9.info------------------
ファイアッー！エムブレム【***】 (237)
シロック最強伝説！ (159)
[PC-98] メタ女 [PC98] (223)
半熟英雄4　7人の半熟英雄　第11幕 (486)
クォヴァディス2・惑星強襲オヴァンレイ stage4 (443)
ルセア＞＞＞＞＞アスレイ＞＞＞＞＞＞＞ミカヤ (262)
FEの武器は聖戦方式に戻すべき (152)
暁の支援会話を封印〜蒼炎風のものにするスレ (519)
ヴォルテールを必死で出撃させるスレ (777)
タクティクスオウガで対戦があったら最強なユニット (286)
FE暁の女神破戒録カイジ (335)
FEキャラのおっぱいついて語るすれ (561)
ティアリングサーガ　強さ議論 (131)
ク　ト　ゥ　ー　ゾ　フ (102)
グレイル傭兵団VS男塾 (110)
【封印】【烈火】ﾌｧｲｱｰｴﾑﾌﾞﾚﾑGBA三作ﾘﾒｲｸｽﾚ【聖魔】 (719)
--log55.com------------------
★2ch.scは何故失敗したのか
★クロール批判要望スレ
★削ジェンヌに文句ある人集合
★迷惑行為報告担当 - 小さな親切募集中 2
★2ch.scへの要望スレ Part3
★かっこう観測所
★スレ立て人キャップ
★2ch.scニュース系板観測所