■ このスレッドは過去ログ倉庫に格納されています

型なし言語逝ってよし

1 ：デフォルトの名無しさん：2001/04/04(水) 12:38: Perl, JavaScript もろもろ型のはっきりしない言語は逝ってよし
2 ：デフォルトの名無しさん：2001/04/04(水) 12:41: ###########このスレ終了###########
3 ：デフォルトの名無しさん：2001/04/04(水) 12:58: もうちょい使ってから言え。
###########このスレ終了###########
4 ：デフォルトの名無しさん：2001/04/04(水) 14:40: せめてなんで逝って良いかいってみれ。
5 ：Variant型：2001/04/04(水) 15:27: >>1
ごめんな。
6 ：デフォルトの名無しさん：2001/04/04(水) 15:41: >>1 形無しだね（ﾜﾗ
7 ：デフォルトの名無しさん：2001/04/04(水) 16:20: 音無です。
8 ：デフォルトの名無しさん：2001/04/04(水) 17:09: 門外漢なんだけどLispって形無し言語？
9 ：デフォルトの名無しさん：2001/04/04(水) 18:08: (yesp)
10 ：デフォルトの名無しさん：2001/04/04(水) 19:08: 型なしだと見つけにくいバグの元になるし、
型ありだと、コンパイルの段階で確実に発見できる誤りが多く
なる。
11 ：デフォルトの名無しさん：2001/04/04(水) 19:13: ('yes)
12 ：void：2001/04/04(水) 19:18: hoge
13 ：デフォルトの名無しさん：2001/04/04(水) 19:34: 型なしのデメリットと型ありのメリットを認識していることはわかた。
型なしのメリットをあげてみれ。
14 ：デフォルトの名無しさん：2001/04/04(水) 19:36: >>9
>>11
t か nil で答えれ。
15 ：デフォルトの名無しさん：2001/04/04(水) 19:57: JavaScriptとか、型が無いからわざわざ変換する必要がなくて、
さくっと何かくだらないもの書くにはいいね。
16 ：デフォルトの名無しさん：2001/04/04(水) 20:00: そうそうコンパイルもしないような言語で型があっても
中途半端に使いづらいだけ。
17 ：ちゅーぼー＆ドキュソ：2001/04/04(水) 20:11: 配列の添え字に文字をつかってみたり(藁
こんなかんじ
a["abc"]++;
18 ：デフォルトの名無しさん：2001/04/04(水) 21:01: Lispは型ありだろ。「強く型付けされて」はいないけど、
型は間違いなく存在する。潜在的な型というんだっけか?
型は変数とではなく値と結びつけられているんだよ。
19 ：デフォルトの名無しさん：2001/04/04(水) 21:32: 「型があってそれを破るのが型破り。
型がないのは型無しっていうんだよ。」
って歌舞伎の偉い人が言ってたな。関係ないけど。
20 ：デフォルトの名無しさん：2001/04/04(水) 22:00: >>19
その論理から言えば、 Variant こそ型破りだな
21 ：デフォルトの名無しさん：2001/04/04(水) 22:13: 形無し言語は初心者がとっつきやすい。
でもそんなとっつきやすさはいらない。
従って1に同意。
22 ：デフォルトの名無しさん：2001/04/04(水) 22:31: 「耳なし法師逝ってよし」に見えた。鬱だ。
23 ：通りすがり：2001/04/04(水) 23:14: 型なしっていうと、アセンブリ言語も含むのかな?
24 ：デフォルトの名無しさん：2001/04/04(水) 23:38: 型変換がめんどくさいとか言ってる人は、
よっぽどキー入力が遅いんだね。（藁
25 ：カン違いクン：2001/04/04(水) 23:40: 型って、テンプレートのこと？　(^-^;
26 ：通りすがり：2001/04/04(水) 23:56: >>24
何を入力すべきか判断するにはもっと時間がかかるのでは？
27 ：デフォルトの名無しさん：2001/04/05(木) 00:19: 実際の所、暗黙の型変換が便利だと思ったのは、
数値→数値と、数値→文字列ぐらいなもんだから、
型無しにする必要なんて全く無いと思う。
28 ：デフォルトの名無しさん：2001/04/05(木) 00:38: 型なし（に近い）ので代表的なのは、PerlとRubyだよな？
後他にあったっけ？
Pythonはっどち？
29 ：キャスト：2001/04/05(木) 00:38: 豚=(デブ)なっち;
30 ：デフォルトの名無しさん：2001/04/05(木) 01:12: >>28
awk
31 ：デフォルトの名無しさん：2001/04/05(木) 01:28: >28
Pythonも形無しに近い、ここらへんの動的なオブジェクト指向言語は(Smalltalkとか)
簡便化以上の理由があってやってるように思えるけどね。
32 ：デフォルトの名無しさん：2001/04/05(木) 01:44: >>31
Smalltalkが簡便化のために動的に？
そんなわけはないです
33 ：デフォルトの名無しさん：2001/04/05(木) 01:53: Smalltalkって型無いの？
34 ：デフォルトの名無しさん：2001/04/05(木) 01:55: >>32
ﾊｧ?(ﾟДﾟ)y─┛~~
説明して見ろよ。んぁ？
35 ：デフォルトの名無しさん：2001/04/05(木) 01:56: 型無し言語わかりずらい
36 ：31：2001/04/05(木) 01:58: >32
あ、書き方悪かったかな？もちろんそのとおり。上のほうで形無しのメリットが
初心者がとっつき易いとか書いてあったから、それだけじゃないんじゃない？
って言いたかった。
37 ：31：2001/04/05(木) 02:02: ＞34
なんで？動的に型定義を変更するためじゃん。ポリモルフィズムとか
より柔軟に行えるよ。
38 ：念のため：2001/04/05(木) 02:04: 型がないというのはオブジェクト・インスタンスの参照を保持する変数が
一種類しかない・型を区別する必要がない、ということ。
オブジェクト自身は特定の型・クラスから生成される。
ってことでいいのかな。
39 ：31：2001/04/05(木) 02:27: ＞38サンの言うとおりですです。
40 ：デフォルトの名無しさん：2001/04/05(木) 03:24: 型なし言語は開発環境の支援が受けにくいから
開発環境が貧弱で古くさくて進歩の止まってる
UNIXでしか流行らないでしょ(藁
41 ：デフォルトの名無しさん：2001/04/05(木) 03:38: JScript?
42 ：デフォルトの名無しさん：2001/04/05(木) 04:04: 本来ホブジェクト指向は
形無し、動的（ガベージコレクション、インタープリタ）
のほうが実装に向いている
43 ：デフォルトの名無しさん：2001/04/05(木) 08:45: で、なんで、型なしだと、便利なの？
なんで動的オブジェクト指向に向いてるの？
44 ：ＳＡＧＥ：2001/04/05(木) 09:32: >>43

>>37-38を読め。
45 ：デフォルトの名無しさん：2001/04/05(木) 09:34: コンパイル時には型あり、インタープリタ時には型なしなどと、
状況に応じて使い分けられる言語があればよいのかな？
それでいて尚且つコンパイルされれば高速で動作する。
そういうのあるのかな？ないならば設計可能だろうか？
46 ：>45：2001/04/05(木) 10:45: >コンパイル時には型あり、
この時点ですでに型あり言語になっちゃってるよ。
型なしはコンパイル時というか実行直前には型を決定できない。

コンパイラと同等のチェックはunitで行える。
47 ：デフォルトの名無しさん：2001/04/05(木) 10:59: 「型なし」って何を指すんだろ。

Ruby だと変数に型は無いけど、データには型があるよ。
1 + "1" はエラー。
48 ：デフォルトの名無しさん：2001/04/05(木) 11:03: >>45
N88-BASICはどうか。
普通の変数名(HOGEとか)は型なしだが
HOGE$だと文字列 HOGE%で整数 HOGE!が浮動小数点と
型を意識することもできる。

個人的には型がどうこうよりも宣言なしに変数を使える言語が嫌だが。
49 ：>>48：2001/04/05(木) 12:20: それは形無しとはいわない。
50 ：デフォルトの名無しさん：2001/04/05(木) 12:33: 型無し言語は、簡単に言えば
整数も浮動小数点数も文字列もポインタもオブジェクトも
全部一つの型だけですませてしまう言語。
51 ：48：2001/04/05(木) 12:42: 省略設楽単精度でした。
逝ってきます。
52 ：デフォルトの名無しさん：2001/04/05(木) 15:24: 型チェックをしない理由

１.　初学者のため。
２.　型チェックがウザいから（昔Pascalが嫌われた理由）
３.　C++のtemplateやAdaのgenericのような、複数の型について汎用性のある機能を実現する際に、
　　　型チェック有りだと、C++やAdaのように複雑な機構と文法を導入しなければならないが、
　　　型チェックなしなら、そのような面倒な一切ない。Smalltalkが好例。
53 ：名無しさん：2001/04/05(木) 15:36: ４．予測できない。
ネットワークからのダウンロードなどで
未知のモジュールと動的リンクする場合、
タグつきの変数などが必要。
悪口を書くと、安定動作するかどうかも
予測できない。
54 ：デフォルトの名無しさん：2001/04/05(木) 16:16: 52には同意だけど、53は不同意
55 ：デフォルトの名無しさん：2001/04/05(木) 17:23: JavaのVectorなんかのようなコンテナ系を見ていると、
いちいちキャストがうざい。
変数に型がないのは利点も多いと思う。
56 ：デフォルトの名無しさん：2001/04/05(木) 19:16: 自分の低脳を理屈で正論化させるなっつーの。
型チェックが甘いことでいいことなんかあるわけねーだろ
開発者側の勝手を堂々とほざくな
57 ：デフォルトの名無しさん：2001/04/05(木) 19:17: >>53
　そういった大きな機能に focus するなら、変数に型があるか
どうかよりも、「型」そのものが first class object かどうか、
reflection が可能かどうかといったような、言語(＋実行時環境)の
機能的な側面の影響の方が大きいと思う。
58 ：デフォルトの名無しさん：2001/04/05(木) 19:32: http://homepage2.nifty.com/katuya/index/index.html
59 ：デフォルトの名無しさん：2001/04/05(木) 19:35: >56
parameterized typeを使用にまぜろ、ってサンにいっとけ。
60 ：デフォルトの名無しさん：2001/04/05(木) 19:39: >>56
ちっさい見通しの聞くスクリプトに型なんていらないよ。
61 ：デフォルトの名無しさん：2001/04/05(木) 19:53: >>56の方が低脳に思えるが…
62 ：デフォルトの名無しさん：2001/04/05(木) 23:29: >>52

３番には意義あり。
タイプセーフのメリットの前には、その複雑さは対したペナルティではない。
大きなプロジェクトでは、構文の複雑さよりも、作ろうとするものの複雑さが問題になる。
逆に形無し言語にとって、簡便さと引き換えに失ったタイプセーフのペナルティは大きい。
大規模なシステムの開発には使い物にならない。
Smalltalkが、あれだけ優れた言語でありながら普及しなかった理由は、
全く実用にならないから。言語として優れていても、道具として劣っている。

そして>>1に戻る。
63 ：デフォルトの名無しさん：2001/04/05(木) 23:49: >>62

実用にならないということはないですよ。

Cincomのホームページを見れば分かるけど
ハドソンの関連会社のプロバイダというのがあって、
そこではSmalltalkを採用することを決めたそうです。
また、そこにはNASDAの名前もあったので、
ああいう言語でもロケットを飛ばせるのか、すごいもんだと思いました。

でもチーム開発にはあまり向かないと聞きました。
64 ：デフォルトの名無しさん：2001/04/06(金) 00:35: Objective-Cのid型は？
65 ：デフォルトの名無しさん：2001/04/06(金) 01:05: アセンブラからCをやると、型変換がうざい。
（字を打つのが面倒くさいんじゃなくって、わざわざ宣言するのが）

言語の基本スタイル的には、
変数の長さ（メモリ使用範囲と言い換え可）があり、
その後、ユーザーが必要であれば型を指定すべきじゃないのだろうか
66 ：デフォルトの名無しさん：2001/04/06(金) 01:25: >>63
Smalltalkで開発しようとした・開発されたシステムはそれほど珍しくない。
しかし、継続して Smalltalk が使われることは少ない。
Smalltalk で作りかけたものを捨てて VB で作り直したという話もある。
それはなぜか？
使ってみれば代わる。
実用にはならないけど、夢を見させてくれる。
Smalltalkは人を惑わせる魅惑の言語だ。
JavaもC++も不完全な言語だけど、実用性ではSmalltalkよりずっと上。
67 ：デフォルトの名無しさん：2001/04/06(金) 01:26: 代わる→判る
68 ：デフォルトの名無しさん：2001/04/06(金) 01:29: >>65
メモリ参照のバグを取ることに比べたら、
型変換の手間のほうがずっと楽だよ。
コンパイラがバグを取ってくれるんだから、
利用しないとソンソン。
69 ：デフォルトの名無しさん：2001/04/06(金) 01:50: 型がない言語なぞクソとか言う人間は
goto使ったプログラムは全部だめとか
GUI以外はすべてだめとか
CUI以外はすべてだめなど
思考停止している低能厨房と同類
よって >>1 が逝ってよし
70 ：デフォルトの名無しさん：2001/04/06(金) 01:56: 型あり->大規模向き
型なし->小規模向き
ってことかな？
Perl, Python, Rubyとかで
大規模なプロジェクトを成功させた実例ってあるのかな？
特にオープンソースもので。
71 ：デフォルトの名無しさん：2001/04/06(金) 02:00: bioperlは、、ちょっと意味合いが違うかもね。
72 ：デフォルトの名無しさん：2001/04/06(金) 02:07: 型が無いと言う点で致命的に大きなマイナスなんだから、
型がないのに良い言語になるわけが無い。
73 ：デフォルトの名無しさん：2001/04/06(金) 02:09: >>70

ないんじゃないの?多分。
PHPならある程度あるだろーけど。

# PHPも、一見型あるけど実際は無いに等しいよな。
74 ：デフォルトの名無しさん：2001/04/06(金) 02:15: >>70
objective-Cはid型だと事実上型無しだけど
CocoaやWebObjectのようなフレームワークも存在する。
75 ：デフォルトの名無しさん：2001/04/06(金) 02:21: めちゃくちゃ苦労すれば劣った言語でも、大規模な物を
作ることはできるだろう。
しかし問題は、それがどの程度やりやすいかということ。
それがおのずと数に表れてくる。
76 ：デフォルトの名無しさん：2001/04/06(金) 02:24: >>70

Cecilという言語のHPみたら
探索的な（Smalltalkのような）プログラミングと
生産的なプログラミングの両方をサポートする
と書いてありましたよ。
型ありのオブジェクトベース言語とかいうものだそうです
77 ：デフォルトの名無しさん：2001/04/06(金) 02:41: 言語に総合的な優劣をつけようとするのは厨房の証明
言語なぞただの道具だから、適正があるだけ。
78 ：デフォルトの名無しさん：2001/04/06(金) 03:00: (変数の：Objectのじゃなくて)型チェックって、
プログラムの中に無数にある「守らないとならんこと」のうちの
1つに過ぎないって感じがするなぁ。だから変数の型くらい
無くなってもあんまり痛くない。
型どころか手続き呼び出しの引数の数さえ形式的に押えられない言語
(Forth系とか)すら有るわけで。

ProC(笑)で、DBのテーブルの構造に「ぴったり」合わせた構造体を
ちまちまちまちま作るウザッタさを思うと、実行時に機械が
合わせてくれるほうがずっとマシ。

変数の型の信者な人でも、C++みたいな境地までいくと
型ゆえに却って面倒だ、と思ったり、しませんか？
少なくともC++は絶対やりすぎだと思う。
型のコンパイル時解釈の迷路(=選択肢が無数に有る中から
正しいものを選ばないとならない)に、自分ではまってるんだもん。
コンパイルが遅いったらありゃしない。

Objectに型があれば、変なことしたら実行時に
例外で蹴ってくれるし。
逆に値のほうの型がふらふらな言語は
使ってて恐いなあ。C++も。

あと、対立ってものでもないぞ、という意見もありそうだし。
javaやdelphiくらいの「中くらいの」言語も有るわけで。
79 ：>8,18など：2001/04/06(金) 03:05: LISPやSchemeは変数（束縛されたシンボル）に型は無いけどデータ型はある。
関数定義もデータ型とみなす事ができる。
変数に格納されたデータ型を判定するには(～p 変数) (～? 変数)などの述語が使える。
よって型の特定が必要な時にこれらの述語を適切に使用すれば実行時エラーは発生しない。
（コンパイラを持つ処理系ではこれらの型情報を使用して最適化されたコードを出力する可能性がある。）
結局、型を特定しない限り安全なプログラムにはならない。
で、あってる？>LISP/Scheme使いの人
80 ：デフォルトの名無しさん：2001/04/06(金) 03:41: >>78
実行してみるまで型が合っているか分からない、ってのが致命的なんでしょうが。
コンパイル時に型間違いといった初歩的なミスを検出できるってのが大事です。
型が違うって例外を吐くようなプログラムが使い物になると思いますか？

それからdelphiが「中ぐらいの言語」ってどういう意味？ Delphi は Pascal 言語が
元なので型チェックは厳しいんだが。

>型のコンパイル時解釈の迷路(=選択肢が無数に有る中から
>正しいものを選ばないとならない)に、自分ではまってるんだもん。

それはあなたの勉強不足＆プログラム構造を把握していないだけ。
81 ：デフォルトの名無しさん：2001/04/06(金) 04:04: >>77
同意。厨房が多いのは春だから？
82 ：デフォルトの名無しさん：2001/04/06(金) 04:08: >それからdelphiが「中ぐらいの言語」ってどういう意味？

PascalとOOPは元々あんまり反りが合わないんじゃないかと
思うのは俺の勝手とはいえ、そう思いませんか？

RTTIなんか使える言語を、型がちがちなだけの言語とは
呼べないように思うです。クラス違い(親子兄弟でもなく)でも
同名プロパティをつつけますから。
＃ん？まぁキャストと同じとも言えるけどさ…

>勉強不足＆プログラム構造を把握していないだけ。

せめてtempleteはGenericJavaくらいまで簡素なものにしたほうが
よいと思うです。

あとこのスレとは関係ないけど、Objectを変数に埋めこめるのも
OOP言語として見れば致命的だよなC++。使いにくいったらありゃせん。

「自分ではまってる」ってのは、それゆえコンパイル遅いべや、
という意味でして。コンパイラが請け負うべき仕事が多すぎ。
83 ：デフォルトの名無しさん：2001/04/06(金) 04:12: あ。あと、TClassの存在も、
delphiを「少し柔らかい」と呼ぶ論拠だったりします。
ちょっと変則的だけどメタクラスもどき。

あれ？C++って今でも、Class(Instanceじゃなく)を
変数に代入したりできないよねえ？
Class(Instanceじゃなく)メソッドの多態も無いよねえ？
84 ：デフォルトの名無しさん：2001/04/06(金) 04:24: >「自分ではまってる」ってのは、それゆえコンパイル遅いべや、
>という意味でして。コンパイラが請け負うべき仕事が多すぎ。

あ、そういう意味でしたか。すみません。

>RTTIなんか使える言語を、型がちがちなだけの言語とは
>呼べないように思うです。クラス違い(親子兄弟でもなく)でも
>同名プロパティをつつけますから。

んー。RTTI情報でプロパティを触るためには、RTTIアクセス関数を使った
プログラムを組まないといけないですよ。RTTI情報をコンパイラが勝手に
使ってプロパティに自由に触れるってことは無いです。

RTTIを使わないでプロパティに触るには、前もって宣言されていることが
必要なので型チェックの厳しさは元祖Pascalとあまり変わりないです。

>＃ん？まぁキャストと同じとも言えるけどさ…

蛇足ですが、キャストと同じではありません。
85 ：デフォルトの名無しさん：2001/04/06(金) 08:31: Perl6では型宣言できるように（ただし義務ではない）なるらしいですね。
86 ：デフォルトの名無しさん：2001/04/06(金) 10:27: interface A{x();y()};
class N : A;
class M : A;

A a;
a = Creator.FactoryMethod();
a.x();

というプログラムがあったとして、別の所で使われていた、
interface B{x();z();}
class P : B;
class Q : B;

というインターフェースBもこのファクトリーからでてくるようにしたい場合、
型があると、BとAの共通部分のインターフェースを作らなきゃいけない、
と思うのだが。それをCとした場合、interface Aとかいてる所を
interface Cと書き直さなきゃいけなかったり、いろいろあると思う。
型が無ければCreatorの中を直せばいいだけ。
これがいいか悪いかは使う人の好みの問題だと思うが？
少なくとも利点が誰にも無い、という事はないと思う。
87 ：デフォルトの名無しさん：2001/04/06(金) 11:41: >86
なるほど。そーゆーのは経験したことあるなぁ。

＃ C#な人なんでしゅね・・。
88 ：デフォルトの名無しさん：2001/04/06(金) 23:31: A しか利用してはならない関数やコンテナで困る。

ある A 用のコンテナの中に間違って B を登録すると、致命的なバグを引き起こすことが判っている。
しかし別のコンテナの中には B を登録したい。
A 用のコンテナと B 用のコンテナは、扱うデータが違うだけで、
ルーチンは全く同じだから共有したい。
規模が大きく、同じ物を２つ作るようなことは避けたい。

こういうとき、C++ ならテンプレートで、型安全と、ソースの汎用性を共存できる。
型のないクラスや、Java のような言語では静的なチェックができない。

AnyContainer<A> con_a;
AnyContainer<B> con_b;

con_a.push_back(A());
con_b.push_back(B());
con_a.push_back(B());//コンパイルエラー
89 ：デフォルトの名無しさん：2001/04/06(金) 23:41: ま、形無し言語擁護派のほとんどは、大規模なソフトウェア開発に
従事したことが無いんだから仕方がねぇよ。
学生か、研究所を出たことがないか、cgiくらいしか作ったことのない奴だろう。
あるいは、一人だけで作ってるのかもな。

そういう小さなプロジェクトなら、形無し言語の簡易性が優れて見えるんだろうが、
中規模以上のプロジェクトになると言語の問題よりも、仕様の把握ミスとか、
連携ミスとか、ドキュメントの準備不足とか、そういうところが問題になってくる。
下請けの会社が、こちらのライブラリを、意図したどおりに使ってくれるとは限らない。
むしろ予想外の使い方をされることが多い。
またテスト・デバッグにかかる時間も長期に及ぶから、言語のデバッグのしやすさが
コストに直接響いてくる。

従って、形無し言語は逝ってよし。
いくらスマートで簡便でも、デバッグに時間がかかる言語は要らない。
90 ：デフォルトの名無しさん：2001/04/07(土) 00:09: >>89

なるほど、説得力がありますね。
でも「いってよし」というほどではない。
91 ：デフォルトの名無しさん：2001/04/07(土) 00:42: 逝って良しと言うほどのことだと思う。
それに、見つけにくいバグ程嫌なものは無い。
92 ：デフォルトの名無しさん：2001/04/07(土) 00:46: ん？つまり用途によって使い分けよう、じゃないのか？
93 ：デフォルトの名無しさん：2001/04/07(土) 02:42: >>92
それ言うと終了しちゃうじゃないか。ほんとに。

ML みたいに勝手に型を推測して欲しいね。C++ には。
94 ：○○：2001/04/07(土) 02:50: GJ使えよ
95 ：デフォルトの名無しさん：2001/04/07(土) 02:55: ＞89
ちょいはずれますが、.NETで言語の枠がなくなるという意見があります。
この場合下請けの人は同じ言語で開発する必要が無くなり、それを実行した場合
デバッグは不可能に近くなります。そう考えると.NETの言語を選ばない
という機能も逝ってよしなんでしょうか。それとも設計、テストにさらに
重要性をおく事で避けうるのでしょうか。
96 ：デフォルトの名無しさん：2001/04/07(土) 06:11: >>89 の発言を論理的に整理すると、
「デバッグ効率の悪い言語は逝ってよし」であって、
「型無し言語逝ってよし」ではないわな。
そこの論理の飛躍に難ありだね。
なお、私は型無し言語を擁護したいわけではない。
私は型無し言語は好まない。
97 ：デフォルトの名無しさん：2001/04/07(土) 10:29: >>86 さんの意見も、型無しの方が面倒な手順を省略できるって論ですよね。
型無しの便利さはそれしかないんでしょうか？

そもそも、型が作られた理由は何でしょう？
（この辺の話は板違いかもしれません）
98 ：デフォルトの名無しさん：2001/04/07(土) 11:02: 機械語を人間にわかりやすくしていったのがプログラム言語と思えば、
型があるのが極めて自然だから… ＞型が作られた理由

逆にOOPを突き詰めていけば型が無い方が自然に思えるんだけれど。
オブジェクトは基本的に任意のメッセージを受け取れて（任意の操作の対象となり得て）、
それに反応するかどうかはオブジェクトの内部実装次第、ってなってるべき。

現状でデバグが激しく面倒なのは同意。>>89
が、その辺は徹底的に形なし思考なプログラム構成を考えてけば、また別の結論にならんかな。
99 ：デフォルトの名無しさん：2001/04/07(土) 11:21: そうか・・・現状では、
特定のメッセージを受け取れるかどうかをチェックすることを、
型チェックで代替しているという見方もできるわけですね。
100 ：デフォルトの名無しさん：2001/04/07(土) 15:18: >>98
おーい。型が「機械にとって」自然なのか？それは初耳かも。
変数の「中」つまりビットパターンの使い方という意味では
たとえば整数とFloatはプロセッサによる取扱われかたが全然違うんで
たしかに機械にとって自然だが、変数の「外」つまり
複数の型を組み合わせる(構造体とかObjectとか)場合には、
単にメモリ上のどのアドレスにどの値を置くか？の違い
でしかないんだから、これが機械との相性問題に発展するってのは
一般的な計算機ではあまり無いことなような気がするが。

構造体をダンプしたパターンをそのまま食わせられるように
設計されたハード(周辺機器とか画面とかかな)っていうなら
わかるが、そーいう場合の配置の「保証」を例えばCはしてくれないわけで、
そういう意味では(少なくともCの)型が機械には役立っていないと思うぞ。
特定コンパイラ実装の特定オプションという限定までつければ別だが、
そりゃそろそろ言語の「型」の議論をするのにしては範疇を越えてる。
101 ：78：2001/04/07(土) 15:27: >>52
>２.　型チェックがウザいから（昔Pascalが嫌われた理由）

Pascal「の」型チェックのやりかたがダサイ、
ということなんじゃないかなあ。

型にも色々ありそうなもので、つーかあるんだけど、
Pascal時代の「全ての型は互いに無関係」ってやり方だと
めちゃめちゃしんどいのな。
型同士の関連性ってのが使えると凄く楽になることがある。
それの1つの解決策がOOPでいう継承だわない。

ちなみに解決策を提示せずに逃げたのがC。尤もあの時代だと
CPU能力および言語研究進行度(ってのは嘘だな：研究者じゃなくて世間
(頭回転速くない人(笑)も一杯いるであろう集合)での認知度の問題か)
からして、しかたないことではあったろうけど。

>>98 >>99
>別の結論
うん。それが無いことはないんじゃないかと思う。
少なくとも無いと証明はされてない…のかな？＞識者よろしく

MLだかいう言語に型推論だかいう仕掛けが有ると小耳に挟んだけど
使い心地どうなんでしょうか？＆どれくらい「問題」を解決して
くれるんでしょうか？＞使ってる人
102 ：78：2001/04/07(土) 15:37: >>88
>ある A 用のコンテナの中に間違って B を登録すると、致命的なバグを引き起こすことが判っている。

いつも不思議に思うんだけどさ。
「間違って登録する」のを防ぐ「ために」型ってのがあるの？
コーディングするとき、色んな変数をあてずっぽう(笑)に
ソースのある個所に突っ込んでみて、
それでコンパイルエラー出ないかどうか？を以って、
その変数をソコに書いてヨイかどうか決定していたりするのか？(笑)

冗談はさておき。つまり変数(値じゃなく)に基づいて
書き間違いをチェックする、1つの手段ってわけだ。

ならば、型以外の色んな概念を使って(も)チェックできるように
なっていて欲しいもんだ。
とりあえずOOPだと、いやOOPじゃなくても
「同じ型の変数」なんて腐るほどたくさん作れるわけで、
それの書き間違いに対しては型チェックは無力なわけよ。
型のチェック「だけ」推挙されても困ってしまうと思う所以がソレ。

例えば。

どうせなら、型と双璧をなす(俺主観)、「ロール」も
チェック対象になるような言語が欲しいです。
ロールプレイングのロールね。つづりはRoleで良いんだっけ？
「役割」って訳されるみたい。
つまりこの変数は「どういう役目の」ものか？を
記述できる言語が欲しい。
たとえばCount RoleとSize RoleはたぶんどちらもInteger型なんだろうけど、
Countな変数を書くべきところにSizeな変数を書いたり(逆も)するのは
多分形式論的(意味論より前)に間違いなのだろうと思われる。
だから、直接書いたらコンパイルエラーになるようにすべき。

型「だけ」じゃ物事を一面的に捉えすぎ。
型と違う(型概念と直交かどうか色々ありそうだが)概念も扱える、
つまり変数チェックの方法として型以外にも色々なものを
(形式的に)扱える、そんな言語が欲しいかも。

＃あ。ここでいってる話は、変数だけじゃなくてObjectにも当てはまると思う。
103 ：>102：2001/04/07(土) 16:13: >どうせなら、型と双璧をなす(俺主観)、「ロール」も
>チェック対象になるような言語が欲しいです。
俺もこれ考えたことある。

でも役割って型=クラスそのものじゃないの？
class Size < Integer
class Count < Integer
とかって型をひたすら細分化してけばいいわけじゃん。

実際にこれをやらないのは単にSizeとIntegerに機能的な違いがないので
手を抜いてそのままIntegerを使ってるというだけで、
クラスを使ってSizeの役割が表現できないということではないと思う。
104 ：デフォルトの名無しさん：2001/04/07(土) 16:16: 型＝クラスにしてしまったのはC++だけでしょう？そんなことない？
105 ：デフォルトの名無しさん：2001/04/07(土) 16:32: >型＝クラスにしてしまったのはC++だけでしょう？
意味わからん。
C++のintやtypedef int Sizeって型だけどクラスじゃないよ？
106 ：98：2001/04/07(土) 17:11: >>100
> 複数の型を組み合わせる(構造体とかObjectとか)場合には、
> 単にメモリ上のどのアドレスにどの値を置くか？の違い
> でしかないんだから、

うにゃー。↑俺が言いたかったのはまさしくここの違いの話でして。
要するに別種の構造体なら、扱い方（＞メモリに値を置く置き方）を
変えなきゃいけないわけだろ？プログラム内のどの場所においても
変数の種類に応じて扱い方を変える、っていうのが要するに「型」じゃないか？
107 ：104：2001/04/07(土) 18:41: ごみん、逆。クラス＝型に訂正>>105
108 ：78：2001/04/08(日) 02:37: >>106
>変数の種類に応じて扱い方を変える、っていうのが要するに「型」じゃないか？

細かい話だけどここが肝なんで。

たとえば型弱い言語のうちの幾つかでは、
「変数じゃなくて値」に「型」をつけてるわけですわ。
型とはなにか？と問われたときに、「変数」という単語が
必ずデフォで出るとは限らない、ってのが、ね。

>>103
>でも役割って型=クラスそのものじゃないの？

うーん。少なくともそう言いきれる理由を俺は知らない。
なんか決定的な理由が有りますか？
反例は…有ったようなきもするけど思い出せない(うつ
従属なんかどうか全然自信ないです。誰か答え知らない？

役割とクラスは、概念的(ぉ)には違うと思うです。
そういやロープレの紙(みようみまねで1回やったことが
あるだけなんでアヤフヤ御免)にClassって欄があったなあ(^^;。
種族って訳すんだっけか。
種族は人とか魔物とか。一方ロールは坊主とか盗人とか。
つまりそういう差だよね、クラスとロールは。

…もしかしてClassと違ってRoleは、動的に着脱できる必要があるかも知れない…
つまり「変数宣言」なんていう呑気なことを言ってられないかも、という。
Classは一度作ったら変化しない(例外はあるが)んで
宣言とかすれば話は解決するんだけど。
109 ：デフォルトの名無しさん：2001/04/08(日) 03:51: >>108
比喩はあくまで比喩に過ぎないので、もう少し具体的
な「役割」の定義を希望します。

どうも「インスタンスの振る舞いなら」に近いことを
考えているように見えますが、それだとクラスと変わ
らない。
110 ：デフォルトの名無しさん：2001/04/08(日) 04:48: >>109
うーん困ったな。俺も全然詰められてないもんでして。
型以外のなんかが有るってのは直感的(笑)には判るんだけど。
＃でも、人と坊主で、説明って足りるんじゃないかなあ？

まぁRoleそのもの(だけ)について言ってもしょーがないんで、
さっき書いたのの延長で、たとえば「着脱可能な、
型と似てるけど別なもの」っていう仕掛けが
有るとしたらどんな使い心地かな？とか考えてみるテスト。

振る舞いを変えさせる必要はないかも知れませんよ。
たとえば振る舞い「を許可」するかどうかを変えるとかね。
アクセス属性「の集合(メソッドごとに属性が付いてるんで、
それらの集合ね)」を一撃で切り替えるとか。
Roleを職能とか権限とか訳すこともあるようだし。
で着脱可能だとすると、場合に応じてRoleをとっかえることで
どのメソッドを使えるか？が変化する。

うむ。また変な案。
「変数には」Roleをつけ、「Objectには」Classをつけたら
どうかなあ？
Objectが生まれながら持ってる能力はClassで記述し、
それを実地でどう使う(使わせてもらえる)かは
変数が決める、っていう。
つまりどの変数を介してアクセスされるか？で
使ってよいメソッドが変化するっていう。
だめ？
111 ：デフォルトの名無しさん：2001/04/08(日) 05:32: なるほどね。今でもカウンタ変数に触ると警告を出すコンパイラ
があるけど、それを拡張したみたいなもんか。つめればいいかも。
112 ：デフォルトの名無しさん：2001/04/08(日) 07:14: 型付けの強い言語が好まれる理由は、
それが自然だからではなくて、単に有益だからだよ。
型が違う変数同士の演算は、間違いである可能性が非常に高いわけ。
これは事実だと思う。
113 ：デフォルトの名無しさん：2001/04/08(日) 07:24: >112
演算だけの問題か？
114 ：デフォルトの名無しさん：2001/04/08(日) 10:10: 型無しの善悪は、その言語の能力とのバランスで考える必要があると思う。

データベースアプリケーションで「削除」ボタンに「よろしいですか？」
の確認メッセージがあるのに対して、「閲覧」ボタンにはそれが無い。

作業を簡便化するだけならば、削除確認メッセージなどウザいだけだが、
これが無いアプリケーションは不安で使ってられない。
間違えて削除ボタンを押してしまった時、取り返しがつかないからだ。
UNDOがあったとしても、そもそも削除ボタンを押したことにその場で
気が付かないかもしれない。

もちろんこれも場合によるが。

それと同じで、言語の「型」というものは、確認メッセージのようなものだ。
記述を間違え、それにその場で気が付かなかった場合、どれぐらいの損失があるのか？
その損失と、型宣言をする労力を比較した場合、どっちを取るべきか？

個人的には、現在ちまたにあふれている一般的なプログラミング言語は、全て型付
けの必要があると思う。
上の例で言えば、全ての言語が「閲覧」以上の機能を持っている。

型無しで書いていいのは、絶対に記述を間違わない人間か、間違ったとしてもたい
した問題を起こさない言語においてのみ許される・・・と思う。
115 ：デフォルトの名無しさん：2001/04/08(日) 13:24: >>114
同意。
形無し言語派の主張は、間違いは後で訂正できる
（実行時にチェックできる）というものだけど、
それは人間が実行時にチェックをするように仕組
まないといけないという時点で、弱い。

機械が自動的にチェックを入れてくれるなら
そのほうがずっと楽に決まっている。

目先の手間にとらわれているようだけど、コーディング
の手間よりもデバッグの手間を軽減してくれるほうが嬉しい。
テスト期間＞設計期間＞コーディング期間。
コーディングの手間なんかにはたいしたコストはかからない。
116 ：デフォルトの名無しさん：2001/04/08(日) 13:32: >>115

ええと。弱型ゲンゴでも、例外あげてくれたりはする
という意味では「機械が自動的にチェック」ではあるんですけど。

値(Object)の型が、勝手に変化するタイプの言語
(awkとか。perlは全然知らないがコッチかな?)と
そうじゃなく例外あげる言語(rubyとか)が有るけど、
一応その差も考慮したほうがいいかも。

型以外の面は結局別の手段チェックしないとならんわけで、
「事前チェック項目が1つ多いか否か」の差でしかない
とやっぱり感じるです。勿論多いほうが良いかもではあるが。

ところで弱型は駄目だと思う人って、
やっぱりOOPの多態も嫌いなんだろうか？
同じじゃないけど少し近いじゃん。
C++は多態嫌いな人が作った言語なんだろうなと
いう気は凄くするけど。
117 ：115：2001/04/08(日) 13:51: 機械があげる例外を漏れなくテストで拾い上げるのが大変なんだろうが。
テスト期間の短縮が目的だといっているのに、それでは意味が無い。
指数関数的に増える組み合わせのパターンによる不具合が、
機械的に漏れなく全部出力されないと困る。

OOPの多態が嫌いってのは論外。
多態ができなきゃOOPなんて成り立たないし。
もし嫌いなら、なんでテンプレートが多態と組み合わせると
おいしいのか説明できない。
118 ：中間報告：2001/04/08(日) 14:20: 型付けの強いOO言語
・大規模向き(型宣言・キャストのタイプのコストが相対的に小さい)
・コンパイル時にチェック可能
・高速(実行時のチェックが少ない。通常コンパイラ)
・統合開発環境と相性が良い

型付けの弱いOO言語
・小規模向き(型宣言・キャストのタイプのコストが相対的に大きい)
・実行時にチェック可能(小規模であればコンパイル時のチェックのメリットが少ない)
・低速(実行時にチェックすべきことが多い。通常インタプリタ)
・UnitTestにより事前チェックが可能
・統合開発環境と相性が悪い
・OOLとしての機能が柔軟で豊富
119 ：デフォルトの名無しさん：2001/04/08(日) 14:32: >>118
・OOLとしての機能が柔軟で豊富 < このへん詳しく知りたい。
UnitTest とかいってる所を見ると Ruby な人と想像するけど、
型付けの弱さとオブジェクト指向言語として機能の関連性を
説明してほしいです。(多態が片付けの弱さと関係あるってことかしら
120 ：デフォルトの名無しさん：2001/04/08(日) 17:01: >>118
Smalltalk（やSELF）は型付けが弱く、かつ完全な統合開発環境を持っているので、
「相性が悪く」はないはずです。

Cecilというわりと新しいＯＯ言語は、動的な型付けと静的な型チェックを
両方兼ね備えた言語らしいです。知っている方います？
121 ：デフォルトの名無しさん：2001/04/08(日) 20:08: >>110
それはまんまポリモーフィズムでは？
変数の型がクラスで、実行時の本当の型がロール。
122 ：デフォルトの名無しさん：2001/04/08(日) 23:02: >>117
>機械があげる例外を漏れなくテストで拾い上げるのが大変なんだろうが。

うん。最初からそう(=正しく)書こうよ。

>指数関数的に増える組み合わせ

ところでXPでいうUnitTestって
まさに指数問題に対する挑戦だと思うんですが。
「Unit」ってところが味噌ね。指数的組み合わせを
行う前にやるテストなのが味噌。
で、型レベルの間違いは「Unit」テストで挙がるよね。
挙がらなかったらそれは使われない機能だから無視
なのだから。XPでは(笑)。

…あ。118の人が既に書いてる。

>なんでテンプレートが多態と組み合わせると
>おいしいのか説明できない。

え？おいしいっすか？
相補的な存在っていうか、片方が出来ないことを
もう片方でやれるって感じはするけど、
2粒で3倍美味しい相乗効果だと思ったことは無いなぁ。

>>121
>変数の型がクラスで、実行時の本当の型がロール。

違うと思う。
その解釈だとたとえば、「長さ」と「重さ」の入れ違いを
コンパイル時に刎ねられないので。

あ。でもそれ以前に俺の案が全然変だな。捨てます。

>>UnitTest とかいってる所を見ると Ruby な人

蛇足ですけど…UnitTestからRubyへの連想って、ちょっと…
本家はJavaでしたっけか。

それはさておき。デザイン「パターン」をしばしば
単なるライブラリにおとしめる(笑)ことが出来るのは
たしかに弱型の「メリット」だとは思います。
FactoryなんてClassが変数に代入可能なら
ごたいそうなコーディングは不要だもんね。
概念の普遍性は残るけど。

>>120
>「相性が悪く」はないはずです。

うい。むしろ弱型のほうが相性よいと思う。
統合環境そのものを実装してるコードが
まるっきり未知のユーザー定義クラスを
扱えるのって、弱型の恩恵の1つ…だよね？
＃勿論色々迂回すれば弱型じゃなくて一見同じことは出来るが。

うーん。あれでdelphiにRTTI解決を勝手にしてくれる構文とかが
追加されたら、お洒落なんだろうな。
123 ：デフォルトの名無しさん：2001/04/08(日) 23:11: >122
>>>120
>>「相性が悪く」はないはずです。
>
>うい。むしろ弱型のほうが相性よいと思う。
型なし言語の統合開発環境って
n．
と打ったときにオブジェクトnのメソッドを列挙したり、
そのメソッドの引数のヒントを表示するってことは、
コーディング時にはできないんじゃない？
nの型がわからないから。
Smalltalkってできるの？
124 ：デフォルトの名無しさん：2001/04/09(月) 00:05: >>123
あ。そっちの話か。
うーん知らないです。
RubyでEmacs(例)な人教えてちょ。
125 ：デフォルトの名無しさん：2001/04/09(月) 00:34: Roleって考え方は面白いね。

>>102
| つまりこの変数は「どういう役目の」ものか？を
| 記述できる言語が欲しい。
| たとえばCount RoleとSize RoleはたぶんどちらもInteger型なんだろうけど、

ここなんだけど、Integer型から派生させたCountRole型とSizeRole型を
作ればいいんじゃないかな。例えばC++のint型は、対応するクラスを
持たないために派生させるということはできないが、JavaのInteger型
であればできる。つまり、RoleはClassで表現可能なのではないかな？

Uvaという言語は、Javaと同じく強い型付けを持つ言語だが、Javaの
プリミティブ型(intなど)にもクラスがあり、Objectを祖とするクラ
スツリーに収まっている。こういった言語であれば、内部的にはint
の実装を持つCountRole型のオブジェクトという表現ができる(土壌
がある)。ただし、使い勝手を考えるとInteger->CountRoleへの
暗黙の変換が欲しいところ。
126 ：デフォルトの名無しさん：2001/04/09(月) 00:53: >125
103が言ってる。
127 ：120：2001/04/09(月) 19:37: >>123
オブジェクトの型が分からない、ということはありません。
むしろ、全く正反対で、オブジェクトが自分自身のことをすべて知っていると考えられます。
C言語のソースで、変数の型を知っているのは、Emacsであって、変数nではありません。
Smalltalkでは
n class
として「print it」（結果を表示）すればnのクラス名が表示されますし、
n class inspect
とすればnのクラスについて調べることが出来ます。
128 ：デフォルトの名無しさん：2001/04/09(月) 19:39: >>127
それは実行時型情報ですよね？
>>123 は開発・コーディング時の話ですけど。
129 ：デフォルトの名無しさん：2001/04/09(月) 19:56: Uvaってまいなーだなー
130 ：デフォルトの名無しさん：2001/04/09(月) 20:00: 誰かVisual StudioとSmalltalk両方使いこなしてる人いないの？
131 ：デフォルトの名無しさん：2001/04/09(月) 20:19: >>128
Smalltalkってインタプリンタで開発環境も含めての実行環境だから
問題ないのでは。
132 ：デフォルトの名無しさん：2001/04/09(月) 20:24: >>131
でも、コンパイル時と、インタプリタの実行時では全然違うと思うんだけど。
133 ：デフォルトの名無しさん：2001/04/09(月) 20:37: みんな、開発方法論とやらに洗脳されていない？
そんな方法論なんてつまらないし、やりたくないし、本当の意味で
開発効率があがるとは思えない。
ちょっとおりこうな人なら、スパイラル開発が一番だって知ってい
るはずだよね？
完全な設計なんて神様でない限り不可能だし、とりあえずプロトタ
イピングして、すこしづつパッチを当てて行く方が実は速いし、プ
ログラミングも楽しくなるってもんでしょ。
と言うわけで CommonLisp一番宣言。
134 ：デフォルトの名無しさん：2001/04/09(月) 20:47: はいはいスレ違い亡者はあっち逝ってね。

開発方法論とやらに洗脳されてるおばかさんをさらしage
　　　　　　　　　　　　　 ↓↓↓↓↓↓↓
>ちょっとおりこうな人なら、スパイラル開発が一番だって知ってい
るはずだよね？
>完全な設計なんて神様でない限り不可能だし、とりあえずプロトタ
イピングして、すこしづつパッチを当てて行く方が実は速いし、プ
ログラミングも楽しくなるってもんでしょ。
135 ：デフォルトの名無しさん：2001/04/09(月) 21:20: スパイラルな開発は、現在のオブジェクト指向開発ではメジャーな開発方法論ですな。

↓ここで「繰り返し開発」って書かれているのがそれ。
http://210.171.126.27/rational/ru/ru_detail.asp?CRS=510008462

これを知らないということはラショナル統一プロセスを知らないということで、
ラショナル統一プロセスを知らないということは UML を知らないということで、
UML を知らないということはオブジェクト指向設計を知らないということである。

133がオブジェクト指向の素人だということの証明終わり。
136 ：デフォルトの名無しさん：2001/04/09(月) 21:34: >>134
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ。

>>135
キミのすさまじい論理展開に乾杯。
137 ：デフォルトの名無しさん：2001/04/09(月) 22:55: スパイラルな開発って何よ？
そんなんアセンブラ時代からやってるよ（藁
138 ：デフォルトの名無しさん：2001/04/09(月) 23:01: 元々｢型｣なんて無いんです。
単なる 0 と 1 の羅列…
それが現在のコンピュータ。

そこに何故｢型｣が導入されたのか？
その後、何故｢型無し言語｣が出てきたのか？

その辺を自分で考えられるようにならなきゃ
プログラマーなんてヤメたほうがイイです。
139 ：デフォルトの名無しさん：2001/04/09(月) 23:41: 形無しｵﾌﾞｼﾞｪｸﾄは恐ろしい。
何でも吸い込んでしまう。
ﾌﾗｯｸﾎｰﾙ夕″。
140 ：デフォルトの名無しさん：2001/04/09(月) 23:55: うひー
141 ：デフォルトの名無しさん：2001/04/10(火) 00:07: >>138
自分でって、最初から意見交換を否定してどうすんだよ。
オタクか？
オマエ、納品間際まで進捗報告一度もしないクチだろ。
142 ：デフォルトの名無しさん：2001/04/10(火) 00:32: >>141
考えた人とは意見を交換するのでは。
確かに考えない奴とは意見を交換したくないよな。
143 ：デフォルトの名無しさん：2001/04/10(火) 02:06: >>125
>ここなんだけど、Integer型から派生させたCountRole型とSizeRole型を
>作ればいいんじゃないかな。

少しは(笑)考えてみました。

で、まぁ現状のC++やJavaみたいな言語を前提として考えるとして、
Integer型とSizeRole型の
どっちを変数の型として
どっちをObjectの型とすべきか？ってのが、
実は困った問題になるんじゃないかなと。
＃変数と型の両方を同じClass/Roleにしてしまうのは無意味なのでパス。

変数がIntegerでObjectがSizeである場合、
代入とかのRole違いをコンパイルではねることが出来ないので駄目(前述)。

変数がRoleでObjectがIntegerである場合、
(C++/Java系つーか、Classを階層として管理する言語を使う限りは)
そもそも代入できない(笑)

てなわけでどっちも無理があるような気がするんです。

敢えて代案を考えるならば、
Javaでいうinterfaceで全部やっちゃう感じかも。
そうすりゃ一応、直交(階層とは無関係)に出来るだろうから。

Integerable、SizeRolable…

…それって、ちょっと悪趣味…

うーん。それとも
interface Sizable{
Integer getSize();
void setSize(Integer);
}
かな？

少なくともサブクラス関係は駄目だと思う。
144 ：デフォルトの名無しさん：2001/04/10(火) 02:11: >>139
ん？型なし「オブジェクト」の話って
今回それほど無かったような気がするけど？
型なし「変数」の話は散々出てるが。

変数だけに(強い)型付けがあって、値のほうには
「全然」無いっていう言語の話って、
たぶん考えてもあんまりメリット無いんじゃないかな…

ところでAWKは値の型が無しだと言って良いんでしょうか？
たしか値の型を非破壊に調べる方法がない言語だったと思ったけど。
145 ：127：2001/04/10(火) 02:14: >>131
>>132
実行時型情報…
Smalltalkではオブジェクトを宣言するというのは
生きているオブジェクトを作成するに等しいのです
Smalltalkには変数に静的な型というものはありませんので「実行時」
の型情報しかありません。Rubyとかも同じといえば同じ。
でもRubyとちがうのはSmalltalkは、より動的であることが自然である、オブジェクトが生きているということです。
146 ：デフォルトの名無しさん：2001/04/10(火) 02:23: ええと、確かこのあたりの議論は - interface で済ませてしまえ、
という原始的なものはともかく - lisp で関数の定義域と値域を
宣言的に記述することによってテストデータを半自動生成するとか、
そんな研究など結構語られていたような気が。20年くらい前かな。

そんでAdaなんかはここらのことに関する巨大な仕様を持ってたり
して、その辺を考えるとこの辺のナニソレはやりすぎると強力だが
人間にとって習得しにくい言語が出来てしまう恐れが...
147 ：>127：2001/04/10(火) 02:24: 結局>123の機能はSmalltalkにはあるの？
148 ：146：2001/04/10(火) 02:24: 「ここらへん」ってのは143方向ね。
149 ：デフォルトの名無しさん：2001/04/10(火) 02:26: >>147
何を列挙すれば「123の機能」になるの？
150 ：デフォルトの名無しさん：2001/04/10(火) 02:31: >>145
そこまで言っちゃうと、ちょっと違うぞと思う。残念ではあるが。

Objectが「生きて」いるか？といえば
RubyだってSmalltalkと同じなハズだし。

あえていえば、(たしか出来るんだったよね)変数「を」
Objectとして色々生かしてしまえば、なにか変わった事が
出来る…のかも知れないけど。

「ソースは」Objectじゃないってのは、味噌だわな。
ソースとObjectは、残念ながらどうやっても
同じ「レベル」にはなれない。
両者の間には、シンボルto値の変換という溝があるだけ。
勿論パーサー(はObjectたりえる)もまたソースじゃないし。

てーかさ、ソースって、どうしようもねーよあれは。
「Objectになれない」という意味では、ね。
＃それ以外のデメリット(????)についてはとりあえずパス。
(テキストで書かれた)ソースってやつは、
少なくともObjectとは目茶目茶かけ離れている。

>Smalltalkではオブジェクトを宣言するというのは
>生きているオブジェクトを作成するに等しいのです

Smalltalkってオブジェクトを「宣言」なんてする
言語なのでしたっけか？細かいことは俺知らないんですが。
オブジェクトを「生成」するだけじゃないか？
＃真のOOP言語ならなおのこと。
そして我々がいじれるのはあくまで「ソース」だけ。
そしてソースはあくまでObjectの生成(操作)「手順」を書いてるだけ。
Objectそのものは結局触れていないよね。
あ。GUIでObjectをいじるかのようなソフトを組めば
むしろかなり生に近いけどさ。

OOPから見てテキストなソースが痛いのは、同一を同一と書けない点。
同一を同値(つまり同じ「単語」が再び出現する)で
代用して表現するしかない。
ついでにいえばそれの延長に存在するのが変数。
同一変数を表現するためにソース上で同値の文字列を再度書く
ことで代用している。
GUIだとさっきと同じ「もの」を掴む(ようなUIを作る)
ことでナントカなるんだけど。

＃というわけで、言語上のObjectとGUI部品とのMapが
＃オプションに過ぎないVC++のダイアログ編集機能は、却下(笑)
151 ：デフォルトの名無しさん：2001/04/10(火) 02:38: >>146

定義域と値域。俺も三日前に(笑)気付いて
結構頭抱えました。

そういやPascalにも
配列のところに簡単な定義域的概念があるんだっけ。
たしかに使ってて面倒になってきます(ぉ

あとMLとかいう言語の超入門を読み始めて、
やっぱりそういう概念が出て来たり。
152 ：145：2001/04/10(火) 02:54: >>150
かなりいい線の事言ってますね（←偉そう＜自分）
宣言ではなくて、生成でしょう。
Smalltalkはたしかにオブジェクトが見えるレベルまで
メタ的な環境ではないですが、まあ、オブジェクトの自主性、能動性という
意味ではかなり高いレベルまでいっているでしょう。
Rubyはそういうオブジェクトの自主性やメタプログラミングというよりは
スクリプト言語としての記述力を自然な形で高めるために使っている
という意味合いが強いと思います。
153 ：デフォルトの名無しさん：2001/04/10(火) 02:59: >Objectそのものは結局触れていないよね。
>あ。GUIでObjectをいじるかのようなソフトを組めば
>むしろかなり生に近いけどさ。
これってコンポーネントだかコントロールだかjava beansのことなんじゃないの？
Delphiのコンポーネントって設計中に既にインスタンスが生成されてて、
はじめてみたときどびっくりしたよ。
154 ：145：2001/04/10(火) 03:03: >>153
そうか、じゃあSmalltalkとかいって粋がらなくても
Delphiでもそういう感覚の一端は味わえるのか

C++ Builderでも？
155 ：デフォルトの名無しさん：2001/04/10(火) 11:27: >>152
>意味合いが強いと
というか、現状の使われかたはさておき、
潜在能力(笑)は似たようなものなんじゃないかと。
決定的な違いを探すと、VM内のそれこそ生きたObjを
ホストOSのディスクにダンプする能力が洗練されてること
くらいかなーと。rubyのVMを明示的に作ろうとかいう話が
英語MLのほうで挙がっているってほんと？＃英語はちょっと…

>>153 >>154

あ。それ言えてると思います。
アレは半ばGUIのサポートのためだけに有る感じはするけど、
delphi/C+Bでは、一応そうでないObjectでもサポートしてる。
＃手掴みできるけどGUI系じゃない「TComponent」というクラスが有る。

おおマヂでインスタンス生成されるんですよねdelphi系って。
DBコンポが設計時にデータ見えるのもソレだし、
そもそもComponentに「今自分は設計環境に居るか？」
と問うメソッドが有る(笑)。だから状況(?)に応じて
むちゃくちゃ(良くも悪くも)な挙動をするObj(のClass)を作れる。

で、そのclassをIDEに「登録」すると使えるようになる。
IDEが未知のclassを操る(少なくともPropertyとかは
幾つ＆どんな型のが有ろうが、自由にアクセス出来ないとならん)
のにはRTTI使ってる。

＃で、生C++じゃそんなこと逆立ちしたってできねー(よね?)んで
＃C+Bはまず言語仕様をdelphi寄りにゆがめる(笑)ことから始まった。
156 ：デフォルトの名無しさん：2001/04/14(土) 16:25: >>119

OOPで良く言われるポリモーフィズムというのは要するに、異なるクラスのオブジェクトに対して同じメッセージを送るということである。

これを静的な型の無い(変数に型が無い)言語で行うのは至極簡単だ。変数が参照しているオブジェクトに対し普通にメッセージを送ってやるだけで良い。要はその変数が参照しているオブジェクトのクラスが異なる場合があるというだけの話なのだ。

静的な型のある言語では、まず異なるクラスのオブジェクトを同じ変数が参照するということが出来ない。静的な型の役割のひとつがそれなのだから当たり前の話だ。だがそれではポリモーフィズムが出来ないのでキャストという魔法を使用する。
あるクラスのオブジェクトの参照は、そのオブジェクトのスーパークラスの参照へキャストできる。この決まりを使うことによって、同じ変数が異なるクラスのオブジェクトの参照を保持することが出来るようになり、ポリモーフィズムが実現できるわけだ。

つまり、静的な型付けを行うことにより、キャストというある種の魔法が必要になってしまうというペナルティが発生するのである。
この問題はコレクションクラスを実装するときにも発生する。C++はテンプレートという仕組みを用意し、Javaはオブジェクトの共通の祖先であるObjectクラスのコレクションを用意することでしのいでる。しかしJavaではほぼ確実にサブクラス側へのキャストという禁忌されるキャストが必要になるので、あまり心象は良くない。

このように、静的な型を取り入れるとOOPは途端に複雑なものになってしまう。
以上、お分かりかな?
157 ：デフォルトの名無しさん：2001/04/14(土) 17:11: >>156
スーパークラスなの変数に
サブクラスなインスタンス(の参照)を
代入することを許す、という程度の規則緩和(笑)は、
流石に今時(いや昔から)の型強言語もやっているんで、
それはちょっと違うのでわ？

＃というわけで、そういうOO的に当たり前の仕掛けを阻害する、
＃C++の変数埋めこみインスタンスは、捨て捨て。

ただし、「必要になる」ってのが
「必要になる場合もある」の意味ならば、合ってるけど。

ところで、OSみたいなものを強型言語で記述しちゃうと、
少なくとも言語のOOPな機能をそのままアプリとの間で
共有できなくなっちゃわないか？
OSをコンパイルしたときに確定してしまうInterfaceしか
使えないので、まるっきり新しいInterfaceを追加したくなったら
OS本体がOpenSouceでないと不可能(笑)ということになりそう。

COMは弱型に属すると言っていい…のかな…？
158 ：デフォルトの名無しさん：2001/04/14(土) 18:24: >スーパークラスなの変数に
>サブクラスなインスタンス(の参照)を
>代入することを許す、という程度の規則緩和(笑)は、
>流石に今時(いや昔から)の型強言語もやっているんで、
>それはちょっと違うのでわ？

　明示的にせよ暗黙的にせよキャストしていることには変わらないと思うが、いかがなものだろうか。
159 ：デフォルトの名無しさん：2001/04/14(土) 18:53: >>156

>つまり、静的な型付けを行うことにより、キャストというある種の
> 魔法が必要になってしまうというペナルティが発生するのである。

どこがペナルティなんですか？
160 ：デフォルトの名無しさん：2001/04/15(日) 00:27: >どこがペナルティなんですか？

もしかしてキャスト大好き人間?
161 ：デフォルトの名無しさん：2001/04/15(日) 01:02: オブジェクトが受け取ったメッセージを処理できなかったときはどうするのよ？
静的な型の無い言語では、この点がペナルティとなるんだが。

静的な型の有る言語では実行前、つまりコンパイル時にチェックできる。
162 ：ねとぅあ：2001/04/15(日) 01:12: ＞161
158-160でキャストの話してるのに、タイミング悪いっすよ。
その意見は結構上の方でみんな言ってるのではないでしょうか。
現状では正しいと思います。ただこれからもっとうまくやる言語
（開発環境）が出てくるような気がしますが。
163 ：デフォルトの名無しさん：2001/04/15(日) 01:19: >158
>>　明示的にせよ暗黙的にせよキャストしていることには変わらないと思うが、いかがなものだろうか。
これ↓は普通（暗黙の）キャストとは言わないし、特にペナルティもない。
>>スーパークラスなの変数に
>>サブクラスなインスタンス(の参照)を
>>代入することを許す、

静的な型付け言語が面倒になるのは
genericなコンテナクラスを作るときのみ。
164 ：159：2001/04/15(日) 01:27: いや、型チェック依存症の人間。テンプレートらぶらぶ :)
165 ：163>164：2001/04/15(日) 01:42: で、C++はSTLに走っちゃったんだよね。
俺はあんまり好きではない（といいつつ使ってるけど）。
内部はvoid*で処理して出入り口で型チェックするような
最小の仕掛けが欲しかった。

C#のコンテナはどうなってるんだろ？
166 ：デフォルトの名無しさん：2001/04/15(日) 02:06: >>158
あれはキャストって言わないよ。
キャストってのは型情報を「いったん捨てて勝手に別なのにすりかえる」
こったろ(なんか違うがまぁ

スーパークラスとかサブクラスとか使うアレは、
変換が許される型へ変換してるだけだから、いいの。

いや、変換ってのは嘘だな。
なんか世の中にはタイプ理論とかいうのが有るとか聞いた
(中身は全然知らぬ)が、それの教えるところによると、
サブクラス化とかいうのは、「1つのObjectや変数に
複数の型を同時に与えたもの」と解釈するのだそうだ。＃ほんと？
サブクラスな変数やObjectは、スーパークラスの型と
サブクラスの型を、同時に持ってると見なすっつー。

だからサブクラスなインスタンスをスーパークラスの変数に
代入するってのは、インスタンスのスーパークラスな面(だけ)を
今は採用しますよって言ってることになる。

>>165
>内部はvoid*で処理して出入り口で型チェックするような

それってGenericJavaに近くない？
チェックは静的だけど、「トランスレーターが」
チェックをするんであって生javacは関係ないから
C++よりもあっさり味のtempleteなのだとか。
＃ほんと？＞識者
167 ：デフォルトの名無しさん：2001/04/15(日) 02:15: アップキャストに何か問題があるの？
サブクラスはどうせスーパークラスのインターフェイス
持ってるんだから、別に何も問題起きないでしょ？

スーパークラスをテンポラリにしていとこクラスインス
タンスをやり取りするとか、そういう邪悪なことをしてる
のか？
168 ：デフォルトの名無しさん：2001/04/15(日) 14:34: アップキャストに問題があるわけではない。キャスト自体が、静的な型のある言語にとっては余り好ましくない存在のはずだ。そのなるべく使いたくないものを使わなければポリモーフィズムを行うことが出来ない、そこがある種のペナルティだといえるだろう。

変換可能だから、問題が起きないからあれはキャストではないというのはどうだろうか。
C言語においてchar*型のポインタをvoid*型の変数に代入した場合、これは暗黙的にキャストされ問題も起こらないが、これは間違いなくキャストが発生しているといえるはずだ。
169 ：デフォルトの名無しさん：2001/04/15(日) 14:54: > キャスト自体が、静的な型のある言語にとっては余り好ましくない存在のはずだ。

それはなぜですか？
170 ：159：2001/04/15(日) 15:01: >>168
深い意味があるのかと思ったけど、アップキャストに関して
「ペナルティがある」というのは単にプログラマの気分の問
題なんですね。じゃ、私は気にしないので問題ない :)

キャストといった場合、float と int の間の型変換のよう
にビットパターンを変更するものと、char * と int * の
変換のように、ビットパターン自体は変えずに型を再解釈す
るものの二通りがあります。（説明が C++ 寄りだけど、言
いたいことは分かるよね？）

私は型チェックらぶらぶな人ですが、前者の型変換は問題視
していません。可能な限り避けたいのは、後者の型再解釈の
キャスト。理由は、これを使うと型あり言語が提供する、コ
ンパイル時型チェック機能を実質的に無効化してしまうから
です。

アップキャストに関しては、たとえ使ったとしても、コンパ
イル時型チェックは依然として有効に機能する（たとえば存
在しないメソッドを呼び出すようなミスはコンパイラが弾い
てくれる）ので、使うに躊躇はしません。
171 ：デフォルトの名無しさん：2001/04/15(日) 16:49: 人間が明示的にするキャストは問題無いよ。
問題はコンピュータが勝手にやってしまう暗黙のキャストだよ。
172 ：>171：2001/04/15(日) 18:00: ＞人間が明示的にするキャストは問題無いよ。
あんた何いってんの？
173 ：デフォルトの名無しさん：2001/04/15(日) 18:03: >>172

おれは優秀だからいーんだってことだろ（藁
174 ：デフォルトの名無しさん：2001/04/15(日) 18:19: >>170
アップキャストにペナルティがあるのではなくて、キャストを使用しなければならないということがペナルティであるということをご理解していただきたい。
何故キャストがペナルティであるかは、ご自身が述べている通り。

アップキャストは型再解釈型のキャストである。型再解釈型のキャストは避けたいという意志があるにも関わらず、アップキャストの使用は躊躇しないというのは矛盾しているように思える。これは明らかに欺瞞であろう。
もっとも、型あり言語でオブジェクト指向を成すためにはアップキャストは避けられない道なのだから、その使用を躊躇っていてはどうにもならない。必要悪の欺瞞と言えるわけだ。
175 ：>174：2001/04/15(日) 18:33: なんか用語の認識間違ってないか？
ベースクラス(=スーパークラス)
アップキャスト：ベースクラス→サブクラス
ダウンキャスト：サブクラス→ベースクラス
176 ：175>174：2001/04/15(日) 18:42: それにアップキャストって型情報は失われない暗黙的な変換だから普通意識しないと思うんだけど。
177 ：デフォルトの名無しさん：2001/04/15(日) 18:53: >>175 の書き方だと誤解がありそうなんで、補足。

アップキャストは、派生クラスから派生元（基底）クラスへと
変換すること。C++ 風に書くと、こう。

class Base {}
class Deriv : public Base {}

Deriv objDeriv;
Base *pBase = &objDeriv;　/* アップキャスト */

クラス図を書くときに基底クラスを上に書くのが一般的だけど、
それに合わせてアップ・ダウンの方向も覚えておくのが良い。

>>175
例外として、C++ で実体を扱う場合には、コピーコンストラク
タに要注意ですね。

もっとも、一般にはオブジェクトといったら参照もしくはポイン
タを使います (Java のように、そもそも実体を使う方法がない
言語も多いし)。C++ でも、積極的に実体を使うのは具象クラス
ぐらい。
178 ：かい：2001/04/15(日) 19:06: キャストって明示的な変換のことを言うんじゃないの？？
179 ：デフォルトの名無しさん：2001/04/15(日) 19:45: >>178
暗黙のキャストもキャストでしょう。

>>174 は、キャストの問題をちゃんと理解していないと思う。
型付言語のポリシーを理解していない。

コンパイラが正当だと判断したキャストにはエラーは出さない。
コンパイラが不当だと判断したキャストにはエラーを出す。
明示的なキャストは、コンパイラが不当だと判断したキャストでも
エラーを抑制してしまう。ここに問題がある。

つまり、キャストはすべてペナルティになるのではなく、
明示的なキャストがペナルティを生むんだよ。
>>170 の人が言っていることと同じような気がするけど、
ここを誤解されると話が進まないから、
安易に流し読みせず、よく考えてくれ。
180 ：デフォルトの名無しさん：2001/04/15(日) 20:57: そうは思わない。明示的でないキャストもかなりの問題を生じる。
なぜならば、「人間が気付かない所でキャストが起きる」からだ。
明示的ならば、キャストの起こっている個所は特定しやすいが、
明示的でない場合、バグの個所がわからない。
181 ：>180：2001/04/15(日) 21:04: 意味わからん。
蝿を昆虫として扱う事のデメリット・ペナルティを具体的に教えてくれ。
あるいはバグの発見が困難であるような具体的なコードを例示してくれ。
言語は問わないから。
182 ：デフォルトの名無しさん：2001/04/15(日) 21:09: >>181
例えば、

hoge=1;
hage="test";

となってるとする。print hageとやりたい所を
間違えて、print hogeとしてしまった時など。
183 ：デフォルトの名無しさん：2001/04/15(日) 21:21: >>182
hoge をプリントするのが正しいのか、
hage をプリントするのが正しいのかは、
人間でしか判断できないでしょう？

どちらのオブジェクトもそのメッセージを受け入れるんだから、
コンパイラが「そのオブジェクトにこのメッセージは送れない」
というエラーを出すわけが無い。
184 ：183：2001/04/15(日) 21:27: 暗黙のキャストがエラーを出さないということは、
メッセージのインターフェイスに矛盾が無いということを保証するだけ。
メッセージそのものが正当かどうかまでは保証しないよ。
この保証の範囲を勘違いしてるんじゃないかな？

強型言語の話をしている人は、前者の保証のメリットと、
明示的キャストでこの保証をスポイルする危険性の話をしている。

182は、私たちが後者の保証までコンパイラに期待しているものと誤解しているよ。
後者の危険性は、確かに明示的であろうと暗黙であろうと危険。
でも強型言語ではこの点については考えられていないし、
型なし言語でも同じ。間違いの無いコードを書くか、実行時に自分で判断する以外に無い。
185 ：デフォルトの名無しさん：2001/04/15(日) 21:54: いや、でもね。
182のような例でエラーになってくれるとすぐバグが発見できる
のに対し、エラーにならない場合は、状況によってはものすごく
発見しにくいことになる（182の状況はあまり適切な状況ではないが）

ようするに、間違って適切でない型を使ってしまったのに、暗黙の
キャストで適切な型に変えられてしまうと、人間が気付きにくいバグに
なってしまう可能性が高くなるわけ。
186 ：デフォルトの名無しさん：2001/04/15(日) 21:56: >>183
できる限りコンピュータが判断してくれた方がいいに決まってる。
182のような例なら、可能性としては判断できる。
187 ：デフォルトの名無しさん：2001/04/15(日) 22:08: >185
わからんです。もう少し具体的（ありそう）なコードを書いてくれませんか？
188 ：183：2001/04/15(日) 22:27: >>186
184を読み直してよ。そこに書いてあるから。
読まない人には、文章で説得することはできないよ。
189 ：183：2001/04/15(日) 22:32: あと、>>182 をエラーかどうかを判断する基準を教えてください。
そんな基準は無いと思うけどね。

万能チューリングマシンでは解決できない問題があることは
すでに証明されているんだよ。
190 ：デフォルトの名無しさん：2001/04/15(日) 22:46: >189
pre/post conditionではねてくれるコンパイラ考えようとしたけれど
無理だった。そーゆーことだな。
191 ：デフォルトの名無しさん：2001/04/15(日) 22:49: 単に>156が型あり言語（と議論の流れ）を理解してないだけだよ。
話が全然かみ合ってない。

>181 蝿を昆虫として扱う事のデメリット・ペナルティを具体的に教えてくれ。
の例でいえば蝿->昆虫のキャストと蝿->金槌のキャストの
（危険性の）違いを区別できてない。

ついでに言えば全く関連のない蝿と金槌を
統一的に扱えてしまう型なし言語は
結局お手軽言語でしかない。
192 ：デフォルトの名無しさん：2001/04/15(日) 23:12: >>191
統一に扱うべきでないオブジェクト群を、
統一に扱うようなコードを書くのが悪いかと。
設計問題だよ。
193 ：デフォルトの名無しさん：2001/04/15(日) 23:39: >>192
もちろん設計が腐ってる場合には、いくら言語が手厚い
サポートをしても無駄。でも、型なし言語だと、

std::string str;
str.length();　// 存在しないメソッド, size() ならある
str.lengt(); // スペルミス

なんてコードを書いても、実行時まで検出できないのが嫌。
194 ：デフォルトの名無しさん：2001/04/16(月) 00:03: >>193
>str.length();　// 存在しないメソッド, size() ならある

それはなんだかむしろ逆なことを感じるなあ。

つまり、ライブラリ「全体」において、
無節操にlengthとsizeという紛らわしいメソッド名を
混在並存させているのが、寒いのでは？

型なし言語派(というのも寒い捉え方だが)なら
むしろそういう心配の仕方をするんじゃないかと憶測。

つまり「名前の」設計ね。

重要だぜ。matz氏の言葉なんぞ引用するまでもなく重要だと思う。
つーかあの言葉を氏が書いていたからこそ、rubyには
ある一定の安心が得られるなあと思うのだった。

実行時まで検出不能というけど、その実行ってのは
単体テストとかのかなり早い段階である「べき」だよね。
たしかにjavaよりrubyのほうがUnitTestを
より強く渇望しているのかも知れない(笑)。
195 ：デフォルトの名無しさん：2001/04/16(月) 00:13: >>194
渇望ってあんた、ベルセルク読んでる？
196 ：デフォルトの名無しさん：2001/04/16(月) 01:06: >>194

>つまり、ライブラリ「全体」において、
>無節操にlengthとsizeという紛らわしいメソッド名を
>混在並存させているのが、寒いのでは？

複数の会社のライブラリを使うのは実務では普通です。
音声認識パッケージを富士通から買ってきて、
自社のサウンドパッケージにかぶせるとき、
「富士通さん、うちの会社では size を使ってるから、
length を size に変えてよ」って言うのか？
これだから研究者は……。
197 ：デフォルトの名無しさん：2001/04/16(月) 01:17: >>185
182で十分だと思うけど。
具体的に何がわからないの？

>>186
> 182は、私たちが後者の保証までコンパイラに期待しているものと誤解しているよ。
> 後者の危険性は、確かに明示的であろうと暗黙であろうと危険。

後者の完全な保証までコンパイラに期待してるわけではない。
それが「一般的な場合に」保証できなくても、182ではエラーで間違いを
訂正してくれることにはかわりはない。
つまり、メッセージそのものが正当であるかどうか「一部」判断できて
いるということ。この点はかなり大きいと思うよ。

> でも強型言語ではこの点については考えられていないし、
> 型なし言語でも同じ。間違いの無いコードを書くか、実行時に自分で判断する以外に無い

実際182の場合、実行時に判断する必要は無い。
強型言語ならコンピュータが判断できる場合も一部にはあるってことだよ。
198 ：デフォルトの名無しさん：2001/04/16(月) 01:22: 例えば、引数などを間違えた場合、型の不一致で
コンパイラがエラーを出してくれる場合が多い。
これは実行時に判断するよりも圧倒的に便利だよ。

ところが、暗黙の型変換されてしまったらエラー
をださずにコンパイルが通ってしまい、実行時に
判断するしかない。これは不便極まりない。
199 ：デフォルトの名無しさん：2001/04/16(月) 01:29: >>187
fprintf(file_stream, format, char_arg);

とすべき所を

fprintf（format, char_arg);

としてしまった。ところが、char* 型がFile* 型
に変換され…
などとなってしまったらどれだけ不便かわかるだろ？
200 ：197：2001/04/16(月) 01:30: >>187と>>189の間違いだ。すまん。
201 ：デフォルトの名無しさん：2001/04/16(月) 01:55: >>199
それは、暗黙の型変換が許されない、したがってコンパイル
時エラーになる例に見えるんだけど。まさか File を char
から派生させてないよね？
202 ：デフォルトの名無しさん：2001/04/16(月) 01:55: 197=198=199 かい？

強型言語が型付けによってエラーを認識できる範囲は、
インターフェイスの正当性に限られ、メッセージの意味にまでは及ばない
というのは判ってもらっていると思う。
それで、さらにオブジェクトの意味についても、もっと深くつっこんで
エラーを検出できるのではないかという質問をしているのだと思う。
確かにそれができれば便利だけど、それは永久にできないだろう。
（しつこいけど、アラン・チューリングを扱った書籍なんかを調べてみてくれ。）

要するに、強型言語の限界を指摘することで、
あまり強い型づけは無意味だと言いたいのでしょう。
だけど意味的なエラーを検出するのは、ごく一部の例外を除いて、コンピューターにはできない。
強型言語は、明らかに矛盾したインターフェイスの間違いを指摘してくれるに過ぎない。

しかしインターフェイスのチェックだけでも非常に価値があることなんだよ。
これによってどれほどの工数を削減したか、計り知れない。
確かに型によってチェックできるところは部分的なものでしかないけど、
だからといって型付けの価値が希薄かというと、そんなことはない。
203 ：デフォルトの名無しさん：2001/04/16(月) 01:58: ところで1はまだ居るんかいな？
204 ：197=198=199：2001/04/16(月) 02:25: >>201
だから、もしもエラーにならなかったら困るだろう？
という話なんだが。

>>202
>それで、さらにオブジェクトの意味についても、もっと深くつっこんで
>エラーを検出できるのではないかという質問をしているのだと思う

いや、そうじゃない。インターフェイスの正当性がきっちりと
検出できれば、エラーで誤りを検出できる機会が多くなるの
ではないかということ。

> 要するに、強型言語の限界を指摘することで、
> あまり強い型づけは無意味だと言いたいのでしょう

ん？俺は暗黙の型変換に都合の悪い点があるといってるのだが。
なんか、かなりの誤解が無いか？
205 ：デフォルトの名無しさん：2001/04/16(月) 02:56: >>204
形なし言語を擁護しているんじゃなかったのか。
スレ違いの話だったんだな。
まぁ相手してやるよ。

暗黙の型変換に問題がある（許さない）としたら、
どういう解決方法がある？

型なし言語にする？
それは全部暗黙の型変換にするということだろう。
何の解決にもなっていない。

型を変換するときは必ず明示的にキャストしなければならないようにする？
それは型変換しているコードはエラーにならないようにすることと等しいだろう。

基本的に暗黙の型変換は、インターフェイスに互換性がある場合にのみ許される。
このようなルールのもとに、インターフェイスに互換性がない部分をふるい落とすことができれば、
機械的なエラーチェックとして十分な効力を持つ。
これこそ型付き言語の基本理念だと思うけど。

次に、インターフェイスの正当性をもっと厳密にして、検出できるエラーを増やすということについて。
ここは C++ や Pascal や Java なんかでは十分に達成していると思う。
多少の改良の余地はあるだろうけれど、現在の理論では、
根本的な解決は望めないでしょう。
UMLの設計ツールからJavaやC++のコードを出力するのは、一つの改良になると思う。
しかしそれでも、メッセージの送信ミスは、コンパイラレベルでは検出できない。
デバッグするか、テストツールに頼るしかないだろうね。
206 ：197：2001/04/16(月) 03:38: >>205
> 型を変換するときは必ず明示的にキャストしなければならないようにする？
> それは型変換しているコードはエラーにならないようにすることと等しいだろう。

なんで等しいんだ？
この場合、間違った型にキャストすればエラーになるだろう？

俺はどっちかというと、CやJava擁護派。暗黙の型変換が型なし言語に比べれば
少ないし、暗黙の型変換が完全に無い方が良いとまでは思ってないしね。
207 ：LINGOさん：2001/04/16(月) 05:38: うーむ、首突っ込みそこねた。悲しい。
208 ：デフォルトの名無しさん：2001/04/16(月) 10:27: >>206
ここでいう「形無し言語」って perl とか VB のこと？
Smalltalk みたいな言語だと、明示的でない型変換はそもそも
発生しない。で、AsInteger で整数化、というようにメソッド
としてしか型変換は存在しない。

で、意味論的にはメソッド名 = インターフェイスとなっている
わけだけど、(isKindOf なんかのテストも含めて)いずれにせよ
実行時テストでしかない、というところが問題だ、と。

Smalltalk やら LISP の流儀のまま、変数や引数や戻り値が特定の
インターフェイス(メソッド群でもよい)を持つことを宣言的に記述
してゆくとどうなるのか、というと...Javaになるのか。

加減算乗除算が可能、大小の比較が可能、何かのオブジェクトへの
参照を保持する、というような軽いインターフェイスが整備されて
いれば、「インターフェイス抽象」が「強い型付け」と結びつけて
受け取られがちな現状は防げたような。
209 ：187：2001/04/16(月) 15:44: >199
頭のなかで流れが十分に理解できていないのだけれど、
暗黙のキャストはどれもだめなの？
僕は181に賛成なんで暗黙のキャストがまずいとは思わない。
たとえば、Javaのコンテナで言えば、

container.add(obj);

とできるところを、

container.add((Object)obj);

としたほうが良いってことですよね？
ああ・・、そうすると、overloadの概念に似ているのか・・。
う～ん。
210 ：デフォルトの名無しさん：2001/04/16(月) 17:43: >>199
型付き言語はC言語だけじゃないぞ。Pascalだって型付き言語だし、Javaもそう。
>>199のミスはPascalでは起こり得ないんだが。
211 ：デフォルトの名無しさん：2001/04/16(月) 21:18: 月光仮面おじさん登場!!!
ホームページを作ったものの、まったくアクセスが上がらな
くて悩んでいる人のためにお役に立ちましょう。
効率よく宣伝できる共有宣伝掲示板を18個設置しました。
全部宣伝して回ればなんと1,000以上の掲示板にカキコしたこ
とになり即、効果が期待できます。さらに共有掲示板の隠し
リンクを発見してそれらも全部宣伝して回ると計2,000以上の
掲示板にカキコしたことになり、さらにアクセスアップを期
待できます。もう、今日からアクセスが無くて悩むことは無
いです。今すぐここからアタックアタック!!

http://home9.highway.ne.jp/cym10262/
212 ：デフォルトの名無しさん：2001/04/16(月) 22:52: Perlプログラマーは他のプログラマーに劣ってはいません。
反論はこちらのスレッドで。
http://tako.2ch.net/test/read.cgi?bbs=perl&key=987424296&ls=100
213 ：デフォルトの名無しさん：2001/04/16(月) 22:56: >>212
激しく同意！！
214 ：デフォルトの名無しさん：2001/04/16(月) 22:58: すみません。Perl板の厨房が暴れているようで...。
放置してやってください。
215 ：デフォルトの名無しさん：2001/04/16(月) 23:24: VB板とかできないのかな･･･
216 ：デフォルトの名無しさん：2001/04/16(月) 23:57: >>215
VB厨房隔離スレ
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=986993653
217 ：デフォルトの名無しさん：2001/04/17(火) 08:31: age
218 ：デフォルトの名無しさん：2001/04/17(火) 12:08: >>208
VBは型無しじゃないぞ。
Vaviant型を指すなら、もっと表現に気をつけるべき。
219 ：デフォルトの名無しさん：2001/04/17(火) 12:09: >>218
Variant型ね。そうなってるか？
ディスプレイ死亡寸前でよめねぇ！
220 ：デフォルトの名無しさん：2001/04/17(火) 12:12: ＶＢ厨房、ＶＢ厨房うるさい人がいるけど、マシンがここまで
高速になったんだからいいじゃん。
Ｃ言語だって、その昔はアセンブラ派から「くそ遅いカメ言語」
「コンパイラにバグはっけん！！俺がコンパイラ作ってやろうか。
ダメダメ開発者くん」
と毎日爆笑されていたことを忘れるべきではない！
221 ：デフォルトの名無しさん：2001/04/17(火) 12:16: というか、ｃ＋＋やっててＶＢ笑っている人っているの？
考え方いっしょだよね。ｃ＋＋ごとき言語もさ。
222 ：デフォルトの名無しさん：2001/04/17(火) 12:21: VBはランタイムが無いと動かないからだめ？
C++も同じだよ。ただ、意識させないだけ
223 ：デフォルトの名無しさん：2001/04/17(火) 13:33: >C++も同じだよ。ただ、意識させないだけ

処理系にもよりますが、たいていはスタティックリンクも選択でき
ます。VBの場合はその選択肢がないことに問題があるんですが。
224 ：デフォルトの名無しさん：2001/04/17(火) 14:09: >高速になったんだからいいじゃん。

それこそ、今時これだけCPUが速くなったのに、
＃今やPDAでも最適化度低いInterpreter言語がさくさく動くんだもんな…
言語の優劣を速度(だけ)で計るほうが間抜けでわ？
225 ：デフォルトの名無しさん：2001/04/17(火) 18:10: ここでもＶＢ叩きが・・・定期的に現れるよねこの話題。
マシン性能が上がったのはいいのですがむしろ客から言われる
のは、「なんで最新のＰＣ買ったのにこんなに遅いの？」
なんだよね・・・
速度も重要なファクターなんだな。

もちろんＶＢでも問題に最適なアルゴリズムを選んだり、
ActiveXコントロールの数を制限したり、実行ファイルやDLLを
分割してロード時間を短くしたりといった工夫は出来ます。

Delphiの様にDLLを必要な時に動的にロード出来る機能は欲しい。
初期ロード時に時間が掛かりすぎるのはつらい。
226 ：デフォルトの名無しさん：2001/04/17(火) 18:16: VBが遅いって言われるのって、たいてい、起動に時間が
かることなんだよね。ディスクがガリガリ鳴ってなかなか
起動しない
227 ：な：2001/04/17(火) 18:37: OOやVBの話になってんなぁ。
awkなんかで、簡単なプログラムを組む時、
一つの変数の内容を数字としても扱えるし、文字列としても扱えるし、
これで楽させてもらったな。
228 ：デフォルトの名無しさん：2001/04/17(火) 18:44: 多態はある意味型無しか？
229 ：デフォルトの名無しさん：2001/04/17(火) 20:11: >224
同意。みんなは言語仕様に対して文句言っているんだろ。
230 ：デフォルトの名無しさん：2001/04/18(水) 02:07: >>228
結局、変数によって「型が全然確定できない」奴と
「一意に確定できる」奴、そして「幾つかに絞り込める」奴の
三種類がある、という言い方が正しいのだと思う。
1つ目は弱型言語。2つ目は強型のうち古典C/Pascalのような類。
そして3つ目が多態つきの強型言語。

変数の側から見た「多態」は、こういう説明になると思う。

Objectの側から見た「多態」は…
なんだろうね(^^;
ちょっと飲まされて頭パーだからまた明日。
＃あ。毎日飲まされてるわけか(笑)
231 ：デフォルトの名無しさん：2001/04/18(水) 21:00: パー万あげ
232 ：デフォルトの名無しさん：2001/04/18(水) 23:28: VBが遅いってあんた当たり前でしょうが。
何のためにActiveＸコンポーネントやら、
ActiveＸコントロールかましてんのよ。
そんなに速さを求めたかったら全部
APiで組みなさいよ。
VBはやる気になりゃあ、ウインドウの
描画から全部APIに置き換えて、Ｃと同等
の速度まで上げられるよ。

ActiveＸを利用して楽チンプログラミング
というVBのスタイルを全く理解してない事に
驚きを感じる。
つーか、ゲーム作るならVB以外でやれよ！
233 ：デフォルトの名無しさん：2001/04/18(水) 23:49: >>232
C++だと以外とゲーム用のフレームワークとかあちこちにあるよね
(ELが良い例)
234 ：デフォルトの名無しさん：2001/04/19(木) 00:07: >>233
たしかに、ゲームを作りたいって時は
C++が一番いいような。

Eiffelとか、Javaとか、Smalltalkとか＾＾；いっても
使えるフレームワークないからね
235 ：デフォルトの名無しさん：2001/04/19(木) 01:17: >>233
ELってたしか、ぞっとするくらいに非OOPなFramework
だったようなオボロゲナ記憶があるんですが…違ったっけ？

>>234
SqueakのMorphなんとかってのが…
ゲームFrameworkではないが、あれはマヂびびった。すごい。

そういやドッカの誰かがRubyでFramework
(ゲームの、だと思うが)を作るとか
Javaで以下同文とか、言っていたようだが、
どうなったかな…
236 ：デフォルトの名無しさん：2001/04/19(木) 02:17: >>235
ELはヘッダーファイルがギョッとしました。
237 ：デフォルトの名無しさん：2001/04/19(木) 02:25: >>236
つかEL=ヘッダファイル
238 ：デフォルトの名無しさん：2001/04/19(木) 03:34: >>237
そう、「あれ？本体は？」と思ってヘッダーファイルを見てみると「ギョッ！」
239 ：236=238：2001/04/19(木) 03:46: あ、実装方法に驚いたってだけで、ELの中身についての事じゃないです。ｱｼｶﾗｽﾞ
240 ：デフォルトの名無しさん：2001/04/19(木) 04:00: たしかに EL のあの実装方法ははじめてみるとギョッとなるよねｗ
そういう方法もあるって事で面白いけど、大きなプロジェクトには
むきませんな。作者も当然わかっててそうしてるとは思うが。
241 ：デフォルトの名無しさん：2001/04/19(木) 15:07: ウリが「EasyLink」なんだから当然なんだろうけど
・グローバル変数ヘッダファイルに書いたり
・関数の多くがマクロ展開されてたり
・クラスを名前空間代わりに使ったり
するのはちょっと恐くはある。

DirectX使っててC++を理解してないということはないだろうけど、
もし作者さんが本当は理解していなかったらと思うと・・・ちょっと恐い。
242 ：239：2001/04/19(木) 18:07: DirectShowのVideo再生とかにも結構早くから対応していたので、
作者さんが混乱しているという事はなさそうです。
作者さんがあの方法で突っ走っている所は素直にスゴイと思いました。
243 ：デフォルトの名無しさん：2001/04/20(金) 02:56: >>242
個々の技術に対応する能力と、言語「に」対応する能力とは
微妙に別かも知れませんので、なんとも言い難く…

ELってたしか、Cマガに紹介記事のったアレですよね。
うーん。あれ読んで、「やばいよこれ」と思った。
あそこまで凄いと、なんていうか
OOPに対するFUDじゃねーか？とか思ったもんでした。
そこまで「OOPは難しい」という発想に凝り固まる必要も
ないんじゃないの？とね。

後輩新人君がゲームを自作したとかいって見せてくれた。
それ自体はまぁ綺麗でヨイ感じだったんだけど、
ライブラリにコレ(だよね)使ってるのを見たもんで、
「おまえ、下げ」って言い放ってしまったよ俺ぁ…。
これからソースをやり取りする仲(=一緒に仕事する)になる相手に
あのノリを覚えられたくは無いなぁと、痛切に思った。
ruby matz氏の言葉じゃないが、あれは簡易つーか安易だよ。

OOを潰すことがそんなに「簡単」を招くんだろうか？
たとえ小規模でも、却ってしんどくなるだけだと思うんだが。
往年の吉田じゃねーが、ゲームにこそOO、なんじゃないの？
244 ：デフォルトの名無しさん：2001/04/20(金) 03:03: >>243
なんだか話がアサッテの方へ逝きそうなので、
とりあえず話題をもどしましょうか。
245 ：デフォルトの名無しさん：2001/04/20(金) 03:09: 御意。戻しましょう(笑)

ええとなんだっけ。そうそう。Objectから見た多態ね。
今日も飲んでるけど(笑)軽快に。

ずばり。関数ポインタが定数じゃなく変数になってること。
以上(笑)。

ただ、そのポインタがどこに有るか？は
言語によって色々なようですね。
多くの言語では(概念上)Classの中に持たれていますね。
Classを値として扱える言語なら、きっとそれ自体が
構造体みたいになってるんでしょう。
そういやCOMが露骨にソレだっけ…
246 ：デフォルトの名無しさん：2001/04/23(月) 13:05: 型なしは、長所であり、短所でもある。
それが解らない、１はアホである。
247 ：C++使い：2001/04/23(月) 15:16: Perl まんせー
ようは適材適所だよ。
248 ：：2001/04/24(火) 00:46: 暗黙の型変換がないと、catch/throwで困ります、どぞよろしく。
Common Lispみたいに、型の宣言したい時に可能であれば、perl、もちょっといい感じ。
249 ：：2001/04/24(火) 00:46: 暗黙の型変換がないと、catch/throwで困ります、どぞよろしく。
Common Lispみたいに、型宣言したい時に可能であれば、perl、もちょっといい感じ。
250 ：デフォルトの名無しさん：2001/04/24(火) 00:57: >>248-249
(catch 'tag body...(throw 'tag result))
だっけ？
resultの最後の評価値がcatchの値
251 ：デフォルトの名無しさん：2001/04/24(火) 02:24: >>248
全然知らない分野みたいです。どう困るか教えてください。

例外の話ですよねえ。うーむ？
{{hogehoge raise}{== hogehoge}{== hogehoge}try}
252 ：デフォルトの名無しさん：2001/04/25(水) 10:27: こんなスレあるの知らなかった。惜しい。

いままでざっと見てきたけど、
　・コードを組みながら設計＝型無し
　・設計を完全にしてからコーディング＝型あり
ってことではないのか？
大規模では設計しないと話にならんから、型無し言語嫌われそうだが。

前の方の「小話で書いたプログラムをあとでVBに移植」みたいな話も
そういうことだろう？
253 ：デフォルトの名無しさん：2001/04/25(水) 12:30: >前の方の「小話で書いたプログラムをあとでVBに移植」みたいな話も
>そういうことだろう？

そうなのかなあ？
なんせVBじゃん(笑)、半分は「VBは要らない」スレの話題に
繋がる恐れがありそうで。単にマーケティングとか
業界勢力図とかのモンダイだという面は、結構あるのでわ？
254 ：デフォルトの名無しさん：2001/04/25(水) 22:02: 不勉強で申し訳ありませんが、使用したいインターフェイスが確かにクラスに実装
されているかをクラス定義時じゃなくて、オブジェクト→インターフェイス参照の
代入時にのみ検証するような言語ってありますか？
255 ：デフォルトの名無しさん：2001/04/25(水) 22:09: >>254
java.lang.Class#isAssignableFrom(java.lang.Class class)

そのまんま。
256 ：254：2001/04/25(水) 22:30: ＞255
ありがとです。
257 ：デフォルトの名無しさん：2001/04/28(土) 13:57: 久々に本題(笑)。

ふと気づいたんだけど、「配列」。

配列そのものを、ひねりのない普通のCLASSとして
素直に実装できる言語って、
型なし言語だけなんじゃあるまいか？

Javaはアレだし。
C++は使い物になる配列はclass templete(用語参考=憂鬱本だったよね)だし。

要するに、型有り言語だと、少なくとも
パラメタライズドクラスとかのワザを使わないと
まともな(型有りに似合った)配列を実現できないのかなと。

もちろんそれが悪いことだと言いきれるわけじゃないんだけど、
ストレートな配列クラスが存在しないと、それはそれで色々と
面倒なことも多いなぁと思う。

というか、面倒の数が掛け算的に増えるんだよね、
普通の変数の型に関わる面倒さよりも。

型有り言語に馴染んだ後に見たrubyの配列クラスは、
その独立性と自由度という意味で、
ちょっとショックだった。
258 ：デフォルトの名無しさん：2001/04/28(土) 14:34: C++ のテンプレート版配列で何か問題あります？　具体例希望。
259 ：デフォルトの名無しさん：2001/04/28(土) 15:38: >>258 例えば整数と実数とリストを同じ配列にぶちこめない
とかじゃないか？
基底クラス作ってサブクラス化すればできるけどよ。
260 ：デフォルトの名無しさん：2001/04/28(土) 15:44: 結局、継承関係(ツリー構造にならねばならんという制約がある)を
解決しない限り、問題解決が先に進まない、というのが
時として厄介な問題になるんじゃないかと。
261 ：デフォルトの名無しさん：2001/04/28(土) 16:30: >>259
単に効率的なインデックス参照を考えている場合は
ポインタの配列という風に抽象化すれば解決します。
262 ：デフォルトの名無しさん：2001/04/28(土) 16:36: つーかコンテナに関しては全部そうじゃん。>257
263 ：デフォルトの名無しさん：2001/04/28(土) 18:07: >ポインタの配列という風に抽象化すれば解決します。

それ、何重にも変じゃないですか？ここの議論的に。

ポインタにしたくらいで抽象化できるってのがまずナニだし
(というか効率とかの話はここでは関係ないし)。
264 ：デフォルトの名無しさん：2001/04/29(日) 19:15: >>262
いやまさにそのとおりなんですけどね(^^;。
とりあえずコンテナの代表者つーかサブクラスの1つとして、
配列っていっただけ。
265 ：デフォルトの名無しさん：2001/04/30(月) 00:07: 型有り言語だと、Classを値として扱うのは
結構大変というか能力制限されるよね。
Delphiでもやっとこせって感じだ。
266 ：デフォルトの名無しさん：2001/04/30(月) 19:45: 型無しの言語って、コンパイル時に型の整合性から
エラーを検出するということが出来ないんだよね？
もしそれが出来ないのなら途方もなく大きなペナル
ティだと思うが、どうやって解決してるんだ？
267 ：デフォルトの名無しさん：2001/04/30(月) 20:05: >>266
例えば
「メソッドがありません。」ってエラーが発生する
そんだけ。
それが問題だったら、例外送出してリカバリする。
コンパイル時に検出できればその時にエラーが出る。
268 ：デフォルトの名無しさん：2001/04/30(月) 20:30: >>267
例えば、文字列しか引数に取らない関数があったとして、
間違って数値が入った変数を引数に与えてしまったら、
実行時にしかエラーが検出できないのか？
269 ：デフォルトの名無しさん：2001/04/30(月) 20:38: このスレunitで検索してみ >>266
270 ：266：2001/04/30(月) 21:00: >>269
結局、いちいちUnitTestやってないと見つからないのか？
それではやはり大きなペナルティだろう。
しかし一応、回避策の一つではあるな。
271 ：269：2001/04/30(月) 21:19: >270
>結局、いちいちUnitTestやってないと見つからないのか？
そのとーり。
UnitTestの有用性は示されつつあるけど、
それが強制されるってのはよろしくないね。
その上デバッガも貧弱だからソース汚してprint
ばら撒かなきゃならないので余計にUnitTestしないといけなくなる。

逆にUnitTestさえやってれば大規模開発
できるのかどうかってことに興味があるね。
Ruby信者あたりが無茶して挑戦してくれないかな :-P
272 ：デフォルトの名無しさん：2001/04/30(月) 22:27: >>その上デバッガも貧弱だからソース汚してprint

それって本質か？
もしかしてGDB(とか)が使えないことを指しているならば、
それは単に「今まで」Cとかが主役だったんで
それ用のデバッガが元気だ、という話でしかないはず。
ようはデバッガ「作れば」いいんでしょ？違う？

>Ruby信者あたりが無茶して挑戦

無茶かなあ？

たとえばCみたいに死にポインタをばんばん作れてしまう言語でも
みんなOSとかばりばり書いている(笑)のは無茶じゃないの？

不便が少ないほうがよいという文意ならば賛成するけど、
ある不便と別の不便とのどっちが深刻な不便か？については
一応考えたほうがよいと思う。

単なる「慣れ」が答えだったら、大笑いかも知れない。
273 ：デフォルトの名無しさん：2001/04/30(月) 23:27: >>272
貶されるのが嫌なのはわかるが、話がそれている。
274 ：デフォルトの名無しさん：2001/05/01(火) 00:22: >>273
逸れてるかなあ？…
少なくとも前半は
むしろアチラが逸れてるんだと思うが。

そうそう。JDBC見て型有り言語にむかついたんだった。
物凄い数(百以上とか)のメソッドがあるんで
なにごと？と思って見てみたら、
同じような機能のメソッドの型違い版がうじゃうじゃあるだけ(笑)

で、更に不思議に感じるのが、出力の返し値の型に応じて
メソッドは多数あるんだけど、入力のほうはOverloadで
同名に揃えているんだよね(笑)。
あれってどっちかに統一できませんかね？
つまりそういう言語作れませんかね？
出力のほうでもOverloadできるような言語。
275 ：デフォルトの名無しさん：2001/05/01(火) 00:56: >>274
私は逆に VBScript + ADO を使ってて、型なし言語にむかついた
けどなぁ。どうも比較がおかしいってんで調べたら、テーブルを
作った人間が、フィールドの型を間違えてたので、型が違っていた
のが原因。……勘弁してくれ。

出力を Overload っていうと、C++ の template に型推論を組
み合わせたような代物？　あれば便利かも。
276 ：デフォルトの名無しさん：2001/05/01(火) 01:00: int f();
int *f();
g(int n);
g(int *n);
で
g(f());
はどう解釈されるの？
なんか無理っぽい気がする
277 ：デフォルトの名無しさん：2001/05/01(火) 02:00: 結局UnitTestしか逃げ道はないのか？
278 ：デフォルトの名無しさん：2001/05/02(水) 00:35: >>276
やっぱそこで頓挫するかあ…うーむ…
279 ：デフォルトの名無しさん：2001/05/02(水) 00:49: 形無し言語は関数のオーバーロードって需要あると思います？
(ていうか、意味あります？)
同一クラス内での話で、多態とは別の話です。
280 ：デフォルトの名無しさん：2001/05/02(水) 01:15: >>279
引数の型じゃ分類できないから、引数の「数」で分類することになるかな。
まぁそれはそれってきもするけど、
たとえばunixのshellみたいな環境を思うと、
やっぱりやめたほうがよいかとも思う。
unixにしばしばある、引数の数で動作を変化させるプログラムって
使っててすごく鬱陶しいと思わないっすか？俺は思う。
＃てゆーかオーバーロードは全部鬱陶しいと俺は思うんだけど。

ところでSmalltalkの文法つーかメソッド呼び出しの引数の書き方、
御存知っすか？
初めてみた(それまではCとかBasic(笑)とかのスタイルしか
知らなかった)ときはびびった。あれ卑怯だよなあ(誉め言葉)。
オーバーロードの是非を悩んでいた自分の肝っ玉が小さく思えた。
はるかにお洒落な解決方法が有ったのに！
281 ：279>280：2001/05/02(水) 01:24: ああ、引数の「数」で区別するんだと、
C++でいう「初期値」を許してる場合区別つきませんねー。
func(param1, param2 = init2)←こういうやつ。
やっぱり意味無さそうですね。
>御存知っすか？
Smalltalkは知りませんが、こういうやつですか？
obj(method, param) //objにmethodメッセージをparam付きで送る。
282 ：279：2001/05/02(水) 01:37: あ、逆だったかな？
obj (param method)
ちなみにSchemeでは何もかも自作なのでどっちでも可(汗
(obj 'method param ...)
(obj param ... 'method)
283 ：デフォルトの名無しさん：2001/05/02(水) 01:50: http://www.sra.co.jp/people/aoki/SmalltalkIdioms/chapter2/Chapter2.htm#KeywordMessage
っす。
いわば引数1つづつに名前がついてる(笑)。
なにがずるいって、「メソッド名」=「1つの単語」じゃない、という所。
copyFrom: 2 to: 4
だったら、
copyFrom to
という2語(笑)がメソッド名であり、引数はメソッド名の「間」に挟まるかんじ(^^;
284 ：279：2001/05/02(水) 02:12: なるほど。複数書けるのは斬新（古いんだろうけど）ですね。
#[10 20 30 40 50] at: 3; copyFrom: 2 to: 4
これは配列のメソッドat,copyFromを呼ぶって事になるんでしょうか。
只の配列の様な無名コンテナにもメソッドがあるのは
独特な感じがします。（ステートメントかもしれませんが）
でも返却値（センダ）は最初のオブジェクト（評価値じゃなくて）
の最後のメソッドの結果なんですね。
↓こうじゃない。
#[10 20 30 40 50] at: 3
30
30 copyFrom: 2 to: 4 => エラー?

最初のメソッドの評価結果は捨てられて最後の評価値が返る。
#[10 20 30 40 50] at: 3
30 =>捨て
#[10 20 30 40 50] copyFrom: 2 to: 4
=>#[20 30 40]
285 ：279：2001/05/02(水) 02:35: うーむ、copyFrom:に対して toは付随する構文にも見れるん
ですが違うのかな？
copyFrom x => x～をコピー
copyFrom x to y => x～yをコピー（コピーするにはyが決定してないと駄目）
to y => yまでを返す。
メソッドが独立だとすると、実際にはx以降全部をコピーし、
y以降を分断するって解釈になりますね。(効率が悪い？)
もしかしたら
copyFromTo x y
とかの方が効率がよくなるとか（汗
286 ：デフォルトの名無しさん：2001/05/02(水) 03:26: >只の配列の様な無名コンテナにもメソッドがあるのは
>独特な感じがします。（ステートメントかもしれませんが）

これはフツーだと思いますよ。rubyもそうだし。

というか小噺なら本気で「すべてObject」でしょうから、
なんでもかんでもメッセージ送りであるはず。
＃Classの定義もSuperclass(だったよね)へのメッセージだし。

「;」は、1つのレシーバへの複数発のメッセージ送りを
連発するための構文、とかでしたよね。うん。

>付随する構文

そゆのはたしか無かったような記憶が。
前述のURLの前後をうじゃうじゃ読むと書いてあったような
気がします(ぉぃぉぃ)が、メッセージ送りの文法は3つあり、
引数なし、引数1つだけ、引数複数、に
分類されるんだったような。
＃で、いわゆる演算子は引数1つのメッセージ送りとして実現されてる(笑)

効率は変わらないと思いますよ。単なる構文。
パーサーがどんなイイ仕事をするか？にだけ依存する問題ですから。
287 ：デフォルトの名無しさん：2001/05/02(水) 14:53: >>283
>copyFrom to
>という2語(笑)がメソッド名であり、引数はメソッド名の「間」に挟まるかんじ(^^;

でなくて、メソッド名というかメッセージ名は copyFrom:to:
コロンは区切子とかそいうのではなくて、単にメッセージ名の一部だったりする。
288 ：デフォルトの名無しさん：2001/05/03(木) 21:21: あげるね。
289 ：デフォルトの名無しさん：2001/05/03(木) 22:49: 2 + 4 * 5
が35。
これは設計ミス？
290 ：デフォルトの名無しさん：2001/05/03(木) 22:54: あ、3 + 4 * 5でした。
291 ：デフォルトの名無しさん：2001/05/03(木) 22:56: >289
どういう計算しているんだ？（藁
292 ：289>291：2001/05/03(木) 23:40: だから>>290で直したでしょ。SmallTalkの話。
293 ：デフォルトの名無しさん：2001/05/04(金) 00:59: オブジェクト指向の話になるとすぐRubyを持ち出す人多いねえ。
「Rubyだと」とか「Rubyでも」とか。
294 ：>293：2001/05/04(金) 02:22: じゃぁ、このスレの次レスから900まではRuby発言禁止。
ぜってー禁止！つーことでみなさんよろしく。
295 ：デフォルトの名無しさん：2001/05/04(金) 16:44: Ruby
296 ：デフォルトの名無しさん：2001/05/05(土) 00:35: >>289
そうか？演算子に優先順位なんてものがあるってのも、
それを算数/数学のソレに合わせないとならないってのも、
なんか必然あるの？イミナイじゃん。
あるとすれば俺たちが義務教育に飼い慣らされたせいだ(笑)
+が*より弱いことの尤もな理由って有る？ないよね？
それどころか計算機言語にこの概念が移植されて以来(特にC)、
計算以外にも多数ある「演算子」にも優先順位っていう概念が
濫用されて、ぐちゃぐちゃになっちゃったじゃん。
優先順位に付き合ってられないから括弧使いましょう、ってのは
プログラムの鉄則の一つになっちまった。結局優先順位って蛇足だっただけ。

そういうウザイものをうっちゃってくれた小噺には拍手。

>>293
rubyが、無難というか没個性(笑)なOOPLだから、じゃないの？
こういう状況で話のネタにしやすいんだよ、rubyの仕様は。
ふつーの(笑)プログラマが、退屈に感じながら想像しがちであろう
仮想OOP言語の仕様って、結構多くの部分がRubyと重なると思う。
勿論演算子優先順位あるし(笑)。
297 ：デフォルトの名無しさん：2001/05/05(土) 00:57: >>296
数学的には
a*(x+y) = (a*x) + (a*y) は成り立つが
a+(x*y) = (a+x) * (a+y) は成り立たない
だから*のほうを強い演算と定義しておくと記述が楽になるのだ。
詳しくは群論とかやるとよくわかるよ
298 ：デフォルトの名無しさん：2001/05/05(土) 01:10: >>296
3 + 4 * 5ってどう見ても中置記法に見えるけど。
+*が「演算子では無い」事を知らなかったら誤解するよ。
メソッドの引数の取り方がobject mehod paramで、
左から順に評価される事を知らなかったら理解できない。
3 + 4 * 5
↓
((object3 method+ param4) method* param5)
↓
(object3 method+ param4) => tmp-object7
(tmp-object7 method* param5) => object35
これはかなり変な感じ。
C++みたいに優先順位固定なのもアレだけど。
299 ：デフォルトの名無しさん：2001/05/05(土) 01:11: そういう考え方だとlispの方が自然だよ。
(* (+ 3 4) 5)の方が誤解なくて良い。
+や*は演算子じゃなくて関数だから優先順位も元から無い。
括弧はウザイけどさ。
必要なら
(infix->prefix '(3 + 4 * 5))
=> (* (+ 3 4) 5)
という手もあるけど。
300 ：デフォルトの名無しさん：2001/05/05(土) 01:35: >>298 >>299
つまり、演算子なんてものが存在することを
忘れりゃ(=計算機畑に持ち込まなければ)ヨイんじゃない？
知らなかったら誤解するもへったくれもなく、
最初から演算子を知らなければ誤解のしようがない。

いや、まさに俺は忘れたいんだけどさ。

Forth系もいいですね。PostScriptなんか結構綺麗。
301 ：>300：2001/05/05(土) 01:47: Forthつーか後置記法だと
3 4 + 5 *
述語が後ろにあるからMIND風に、
「3 と 4 を足して 5 を掛ける。」
=> 35
と書ける。'と'や'を'は区切り子。
302 ：デフォルトの名無しさん：2001/05/06(日) 00:25: コンパイラが賢くなって、型推論がもっと進めば
型付けが強い言語は廃れてくんじゃないかなあ・・
型付けが強い言語でガチガチに組むの疲れるんで、そうなってほしい。
303 ：デフォルトの名無しさん：2001/05/06(日) 01:13: 型推論といえばMLが思い浮かぶんですが、
書きやすさや実行効率はどうなんでしょうか。
304 ：デフォルトの名無しさん：2001/05/06(日) 01:20: MLは型推論を取り入れた、「強く型付けされた言語」だよ。
型推論と型多相の概念があるから、型があっても定義は少
なくて済む。型による厳密性を保ちつつ、柔軟性も実現で
きている。
型推論というのは、型が廃れるどころか、逆に型のある言語の
不利を解消してくれるものだと思う。
305 ：デフォルトの名無しさん：2001/05/06(日) 01:24: 型推論でgcを全く使わない処理系が存在するらしい。>303
関数型言語スレにリンクがあった筈。
書きやすさは、慣れればCと大して変わらないと願いたい。(w
306 ：293：2001/05/06(日) 01:32: >>296
rubyが没個性という意見は共感できます。

ちなみに、Rubyのドキュメントなどに
「教育上の配慮としては」
というフレーズが出てくることからして、Ruby開発者周辺は
Rubyを教育に使える言語だと思っているらしい。
俺はそれにはちょっと疑問を感じる。
307 ：デフォルトの名無しさん：2001/05/06(日) 01:37: MLと同じような言語であるHaskellにはGCあるよ。
クイックソートは次のようになるらしい。

qsort [] = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
where
elts_lt_x = [y | y <- xs, y < x]
elts_greq_x = [y | y <- xs, y >= x]

C言語よりは書きやすそうだ。
308 ：デフォルトの名無しさん：2001/05/06(日) 02:05: >>302
型の無い言語でちょっとしたミスが次々とバグになっていく
方が疲れる。
型がある言語はコンパイル段階でバグがある程度発見されるから
ある種の信頼感のようなものがあっていい。
309 ：かたなし：2001/05/06(日) 02:16: 型がなくてもいいかなと思いますね。

- 契約に基づくプログラミング
- Testing Frameworkによる保証

的なことがないと、チームで使う気にはなれませんが。
310 ：デフォルトの名無しさん：2001/05/06(日) 02:26: Testing Frameworkを適用するにしても、全ての関数に関して
Unit Testを実行するのか？
なんか、型による効率を全面的に回復してくれるものとは
思えない。
それに、契約によるプログラミングでも、ケアレスミスを犯して
しまったら、実行時のバグになるから、型によるチェックの代替
になるようなものでもないと思う。
311 ：>308：2001/05/06(日) 02:31: そういう人に限ってテストをおろそかにする傾向があります。
(「コンパイル通ったから」つって人に渡す様な人ね。)
>ミスが次々とバグになっていく
このセリフが全てを物語っているのでは？

形無しだと単体テスト前提なのでそんな事はありません。
312 ：デフォルトの名無しさん：2001/05/06(日) 02:33: >>311
単体テスト前提ってどういうこと？
引数間違えたら実行時のバグになるだろ？
313 ：デフォルトの名無しさん：2001/05/06(日) 02:41: 引数間違えるのをテストケースの一部にすればいいんじゃないの？
頭悪いの？>312
314 ：うーんと：2001/05/06(日) 02:41: あれま、これまでのレス全部よんだんだけど、
かたなし擁護派が、Testing Frameworkやら持ち出す戦法は
とっくにやられてるのね。じゃ、なんか、新しいこと書かないとね。

形無しは、あるていど小人数のプロジェクトに限られちゃう傾向が
あるのはそのとーりでしょうね。あと全メソッドに対してテスト書くのか？
っていう突っ込みいただいてますが、それはそんなことはしないです。
pragmaticに考えましょ。っていう回答になりますね。

>>312
引数間違えくらいのものでしたら、単体テストの段階でひっかかるでしょうね。
315 ：あとあと、：2001/05/06(日) 02:48: でっかいものをかたなしでやれんのか？　というお話でてますが、
こんぽーねんと、というかカタマリにしてやって、それより外は

- えーい、CORBAをしゃべらせちゃえ
- SOAPいってみる

なんて、型の世界も利用しちゃったりするのもありだし。
316 ：デフォルトの名無しさん：2001/05/06(日) 02:50: だから、要するに単体テストなりUnit Testなりが前提ということは、面倒って
ことだろ？
ていうか、全部の関数をテストするわけじゃないんだから、全然駄目だと思うんだが。
317 ：デフォルトの名無しさん：2001/05/06(日) 02:51: ところで、MLの型推論は型無し派から見てどうなんすかねぇ。
318 ：うへ、こりゃたまげた。：2001/05/06(日) 02:52: 型あり普段つかってっけど、単体テスト便利よ。
Testing Frameworkはべつに形無し野郎の専売特許じゃないっしょ。
319 ：デフォルトの名無しさん：2001/05/06(日) 02:54: >>318
確かに便利でも、それさえあれば型による不利が全部なくなってしまう
というものでもないと思うのだが。
むしろ型あり、無しとは関係の無い所で新たな便利さを付加するもの
であると思うけども。
320 ：だめプログラマーと呼ばれちゃうかも>おいら：2001/05/06(日) 03:02: おいらも含めて世の中ろくでもないプログラマーばっかだから、
型で守られてても、信用なんねー、イテテ、という目にもあうし、

テストがついてないと心配だし、テストがついてたら、まぁその範囲で
信用しましょ、で、細かいところは見てる暇もないから、とらぶったら、
中身もみます。
321 ：デフォルトの名無しさん：2001/05/06(日) 03:03: >316
単体テストは別に面倒ではないよ。
型に縛られる言語は思考の妨げになっている事が多い。
322 ：形無し擁護派の資格はないけど：2001/05/06(日) 03:04: >>317
型推論って詳しく知りませんスマソ
ラクチンできるとか、いろいろ餌を与えてくれれば
尻尾ふってよろこぶプログラマーは多いと思います。
323 ：デフォルトの名無しさん：2001/05/06(日) 04:34: >>321
何もしないよりは面倒だから全部の関数をテスト
したりしないんだと思うけど。違う？
324 ：デフォルトの名無しさん：2001/05/06(日) 04:42: 結局は、手間がかかるからテストは限られる。
テストは型の無い言語が失ったチェック機能を完璧に
補うことにはならないと思う。
その代り、型の有無に関係の無いメリットをもたらす
ものだと思う。
325 ：デフォルトの名無しさん：2001/05/06(日) 10:03: >>313
何か勘違いしてないか？
引数を間違えるというのは、hoge(a, b)をhoge(b, a)に間違えて
呼び出してしまった場合など。
この時、型の有る言語ならコンパイル時にこのバグを発見してく
れる可能性が高いけど、型が無いと実行時のエラーになる。
間違えるつもりはなかったのにうっかり間違えてしまったのだから
テストケースにすればいいという問題でもないだろ？
326 ：えっとね。にーちゃん学生？：2001/05/06(日) 10:19: >>325
呼び出し側の単体テストで引っかかるとか。
あるいは呼び出し側で単体テストがなけりゃ機能テストで引っかかるね。
で、あわてて、こりゃまずいね。引っかかるように単体テスト用意しとこね。
って話になるような。

あと、Programming by Contractの場合は、メソッドの入り口の検査で
ひっかかるよね。
327 ：デフォルトの名無しさん：2001/05/06(日) 10:25: >>326
でもそれだと、呼び出し側の関数内にエラーがあることしかわからない。
結局、不利なことにかわりは無いと思うが。
328 ：100％もいいけど、コストバランスもね。：2001/05/06(日) 10:37: >>327
心配してるのがランタイムエラーの防止なら目的は達成できてるっしょ。
329 ：デフォルトの名無しさん：2001/05/06(日) 10:40: >>328
いや、問題はどれだけ直ぐにどの個所にエラーがあるかを
特定すること。
その点ではランタイムエラーや、実行時のエラーとならないバグは
コンパイルエラーと比べてタチが悪いってこと。
結局、コンパイルエラーほど便利なものは無い。
330 ：やべ、だだっこモード入ってきた>おいら：2001/05/06(日) 10:46: なるほど。
型システムのメリットを否定するつもりはございません。
ケースバイケースですが、はまることもあるのは事実でしょうね。

いじわるな例:
(int,int,int)な型のメソッドって順番変わってもだめじゃーん。
331 ：デフォルトの名無しさん：2001/05/06(日) 10:50: >>330
まあ確かに、型によるコンパイラのチェックと言っても万能じゃない。
でもかなり有効なのは間違いないと思うが。
332 ：今度は：2001/05/06(日) 10:59: 形無しのメリットを聞いてみたかったり。時間あったらよろしく！
おいらこれから新幹線のってお仕事なんだな。はぁ。
じゃまたね。
333 ：デフォルトの名無しさん：2001/05/06(日) 11:50: >>330
>いじわるな例:
>(int,int,int)な型のメソッドって順番変わってもだめじゃーん。
IDEのエディタは入力時に
foo(int size, int count, int length)
のようなチップヘルプを表示してくれて
どの引数が何を意味してるかを教えてくれる。
順番間違えるなんてミス最近したことないな。

>>332
>形無しのメリットを聞いてみたかったり。
記述が冗長でない->シンタックスシュガーってだけでしょ。結局。
>>118参照
334 ：デフォルトの名無しさん：2001/05/06(日) 17:59: >>333
ということは、VC6のように、IDEさえしっかりしていれば、
型なんていらないということにならないか？
335 ：デフォルトの名無しさん：2001/05/06(日) 19:22: >>318
んだ。型ってのは、無数にあるであろうチェックしなきゃならん事柄
のうちの一つなんで、型あろうがなかろうがUnitTestは役立つ。
というか、コンパイラが変数の型を調べるってのはつまり
型に対するUnitTestをコンパイラ(と言語の文法)が内包している
ということに他ならない(笑)。

>チップヘルプを表示してくれて
>どの引数が何を意味してるかを教えてくれる。

それって「Role」に話通じるよね。
というかツールチップがしてくれるその仕事ってのは
Roleのサブセットに過ぎないんじゃないかと思う。

ところで型の話と関係ないが、
VC6ってしっかりしてるといえるのかなあ？
俺は処理のデバッグだけじゃなくてObjectのデバッグもしたいが、
VCでもあまり積極的にサポートされてないよね。
あるインスタンス…変数じゃなく値Objectを、
Scopeに依存しない形で状態変化の追跡をしたい
と思うことが多いのだが、不可能か面倒かどっちかだよね。
だからいつもストレス感じている。Instance(クラスじゃなく)「に」
ブレークポイントというかWatchを置きたいのにのに。
336 ：デフォルトの名無しさん：2001/05/06(日) 19:27: >>334
前にもあった話だけど、型なし言語で
Object(の型)に基づいたメソッド名一覧を
出せるのか？という疑問があったようだし。

で、その話を外挿すると、多態を使うと
メソッドの「名」は表示できるが、
メソッドの「実装」へワンタッチでジャンプする
ような仕掛けってのは、破綻するといえるよね。
そういやVCでも、メソッド名の定義だか実装だかを
検索させるときは、同名メソッドの一覧をずらりと
提示してくれちゃうよね。絞りようがないとも言える。

型も勿論便利だけど、型だけじゃやはり太刀打ちできないので、
少なくともコンパイルエラー「だけ」を頼るような
ドキュなプログラミングスタイルは逝ってくれないと困る。
337 ：デフォルトの名無しさん：2001/05/06(日) 20:12: >>332
型なしのメリットは自由度だと思う。
継承関係とかにとらわれずにプログラミングできる。

自由度は諸刃の刃ではあるけどね。
338 ：デフォルトの名無しさん：2001/05/06(日) 21:20: 型無し言語は実行時エラーでしかミスを判断できない、
という意見があるけど、なんか、
型無し＝インタプリタ、型あり＝コンパイラ、という
前提を元に批判しているように思える。
僕の勘違い？
339 ：デフォルトの名無しさん：2001/05/06(日) 21:57: >338
もう少し詳しく説明してよ。
そうじゃないと君の書き込みは厨房な書き込みに見える。
340 ：＞338：2001/05/06(日) 21:59: > 型無し言語は実行時エラーでしかミスを判断できない、

この意見は別に

> 型無し＝インタプリタ、型あり＝コンパイラ

こんな前提なぞ関係無しに成り立つ話でしょ。
341 ：デフォルトの名無しさん：2001/05/07(月) 00:19: >>335
チップヘルプの話をしてるのに、いきなりなんでデバッグに話が飛ぶの？
全然会話がかみ合ってないよ。
342 ：338：2001/05/07(月) 00:34: >>339
最近のレスでいうと、>>325のケアレスミスの件は、
コンパイル時に見つけられればOK、実行時に見つけられれば
NG、という括りをしているように読めました。
>>329の「コンパイルエラーほど便利なものは無い」というのも
型あり言語のコンパイラを前提としたレスに読めました。

前提が無いのなら、そういうアプリケーションの機能ではなく
言語の文法や機構等につっこみを入れるべきなのではないかと
思います。

>>340
型あり派の人たち全員がそういう前提で話しているとは言いませんが、
上記のレスの印象から、そういう人たちが混ざっているように感じました。
言葉が足りませんでした。気分悪くしたらゴメンナサイ。
343 ：デフォルトの名無しさん：2001/05/07(月) 00:38: >>342
だから、型なしだとコンパイルの時にエラーが発見できないんだよ。
コンパイラだろうがインタプリタだろうが。
わかってる？
344 ：デフォルトの名無しさん：2001/05/07(月) 00:39: 最近は純粋なインタープリタってあまり見ないよね。
345 ：338：2001/05/07(月) 00:48: >>343
いえ、型無しに関してはそうなのですが、
型ありのインタプリタというのは
考慮されていないということでしょうか。
私も型ありのインタプリタの実例を知らないので
何ともいえないのですが。
346 ：え、：2001/05/07(月) 00:49: PerlもPythonもRubyも不純？
347 ：デフォルトの名無しさん：2001/05/07(月) 00:51: 実行前に中間コードに変換するから？
348 ：338：2001/05/07(月) 00:52: >>343
型無し＝インタプリタ、という前提は私の勘違いでした。
ごめんなさい。
349 ：>345：2001/05/07(月) 00:56: C/C++のインタプリタって存在するよ。
利点はバイナリ作らなくても実行できてお手軽ってだけ。
コンパイラ・インタプリタ（純粋・中間コード）の区別って
基本的には速度が違うだけで機能面では差はないよ。
# CPUがインタプリットするかインタプリタがインタプリットするかの違いだから

ついでに、型無し言語のコンパイラってあまり意味がない。
結局バイナリ自身にインタプリタ的な
機能を持たざるを得ないから速度が出ない。

ただソースを隠せるという副作用があって
こっちのほうがメリットがあるかもね。
350 ：デフォルトの名無しさん：2001/05/07(月) 00:59: >>349
そのC/C++のインタプリタでは、例え純粋なインタプリタでも
実行前にエラーを出すんですか？
出せないなら型の意味が薄れることになるけど。
351 ：デフォルトの名無しさん：2001/05/07(月) 01:03: この板UnitTest=TestingFrameworkの話題が結構出てくるけど
実際どの程度の人が実践してるんだ？
XPの完全導入なんて皆無だと思うんだけど。

「設計サボって後から泣く泣く手直し」を
リファクタリングって呼んでるやつは多そうだけど(藁
352 ：デフォルトの名無しさん：2001/05/07(月) 01:04: >>350
その前に、C/C++の純粋なインタプリタって存在するのですか？
353 ：>350：2001/05/07(月) 01:04: インタプリタの実装の質による話だよ。
CINTのソースでも呼んでみれば？
354 ：だから：2001/05/07(月) 01:05: 癒し系っていわれんじゃないの。> XP,Refactoring,TestingFramework
355 ：デフォルトの名無しさん：2001/05/07(月) 01:12: 初芝電気の会長のセリフじゃないが、
愛がなきゃチームはうまくいかない。
356 ：338：2001/05/07(月) 01:29: >>349
CINTというインタプリタは知っています。
ただ、動かしたことがありませんので詳細はわかりません。
357 ：デフォルトの名無しさん：2001/05/08(火) 08:01: >>356
型有り言語は静的な型のチェックが可能です。つまり実行する前に型の間違いを
見つけることが出来ます。(型無し言語は動的な型チェックしかできない。)

型有り言語のコンパイラ／インタプリタであっても、静的な型チェックを行わず
動的な型チェックのみを行う実装がもしかしたら存在するかもしれない。

言語の仕様的に静的な型チェックが可能かどうかが大事なので
ここでコンパイラ／インタプリタの話を持ち出すのは無意味。
358 ：デフォルトの名無しさん：2001/05/08(火) 21:14: test1
359 ：デフォルトの名無しさん：2001/05/08(火) 21:14: test2
360 ：338：2001/05/08(火) 21:22: >>357
コンパイラやインタプリタを前提にしているというのは
僕の勘違いということで納得しました。
私が指摘した>>325や>>329等は文脈的に「コンパイラ」という
単語が出てきただけという認識に改めました。
以上。失礼しました。逝ってまいります。
361 ：デフォルトの名無しさん：2001/05/18(金) 06:24: age
362 ：デフォルトの名無しさん：2001/05/19(土) 04:55: 逝かなくて良しage
363 ：デフォルトの名無しさん：2001/06/16(土) 14:56: 急浮上
364 ：>363 なんかネタふってよ：2001/06/16(土) 15:25
365 ：363じゃないが：2001/06/16(土) 18:47: 型無し言語も、型推論による型チェック導入すれば逝かなくて良し！
366 ：363じゃないが：2001/06/16(土) 18:48: というネタはどうよ？>364
367 ：デフォルトの名無しさん：2001/06/16(土) 23:43: >>365
型チェックする時点で型あり言語。
368 ：デフォルトの名無しさん：2001/06/21(木) 03:04: 型無し言語＋型推論　＞　型有り言語　＞　型無し言語
ですか？
369 ：デフォルトの名無しさん：2001/06/21(木) 03:27: > 型無し+型推論
ってなんだ？
そんな言語ないだろう？
MLは型あるし。（しかもキツイ）
370 ：デフォルトの名無しさん：2001/06/21(木) 03:35: >型無し言語＋型推論
明示的型宣言の必要無い言語って意味？
MLは推論失敗したら型聞いてくるよ
371 ：デフォルトの名無しさん：2001/06/22(金) 01:30: Smalltalkは動的に強く型付けされた言語(データ型あり)
Eiffelは静的に強く型付けされた言語(データ型あり)
Pascalは静的に強く型付けされた言語(データ型なし)
C++は静的に弱く型付けされた言語
型なし言語ってBCPLみたいなのをいうと思う。
372 ：デフォルトの名無しさん：2001/06/22(金) 01:31: BCPLはモノタイプじゃないの？
373 ：デフォルトの名無しさん：2001/06/22(金) 01:38: >>371
OOP言語は、
(Objectについてはという意味で)必ずデータに動的な型が有るよね？
C++もDelphiもJavaも。そうでないと多態ができない。

型無し言語っすか。awkなんかが該当するんかな。
外因によって暗黙のうちに型(?)が変わっちゃう。
374 ：371：2001/06/22(金) 01:58: >>372
モノタイプは型なし言語だと思う。
375 ：デフォルトの名無しさん：2001/06/22(金) 02:29: 型無し言語というのは、一般的には、コンパイル時において、
変数の型が決まっていない言語のことだろ？
だから、Smalltalkは型無し言語だろう。
型推論というのは、コンパイル時に型を推論して演繹し、決定
する行為の事を呼ぶのだから、型無し言語＋型推論というのは
普通は、ありえない。
型推論なら、型有り言語。
部分的に型無し言語＋部分的に型推論というのなら、可能性
としてはありえる。
376 ：デフォルトの名無しさん：2001/06/22(金) 03:06: 変数に型がある=静的型
オブジェクトに型がある=動的型
377 ：デフォルトの名無しさん：2001/06/22(金) 06:44: >>375
そもそも「コンパイル時」って解釈がおかしいよ。
HaskellやMLにはインタプリタもある。
378 ：371：2001/06/22(金) 07:50: >>375
Smalltalkは型あり言語
379 ：デフォルトの名無しさん：2001/06/22(金) 10:35: >>377
正しくは、「プログラムが実行し始めるより前に」だな。
ところで、HaskellやMLの代表的なインタプリタは中間形式に
コンパイルするぞ。
380 ：デフォルトの名無しさん：2001/06/22(金) 10:38: >>378
Smalltalkは普通、型無し言語と言われていると思うが･･･
381 ：デフォルトの名無しさん：2001/06/22(金) 10:41: 正確には違うかもしれないが、
変数に型があるなら、型有り言語
オブジェクトだけに型があるなら、型無し言語
だろ？
382 ：デフォルトの名無しさん：2001/06/22(金) 10:59: Perlの型あり言語の仲間になるらしい。知らなかった。。。
383 ：デフォルトの名無しさん：2001/06/22(金) 11:09: Perlは最も不細工で半端な型有り言語だな。
型を（有限な）記号で明示するなんてセンス悪すぎ。
384 ：デフォルトの名無しさん：2001/06/22(金) 11:11: >>382
Perlの変数に使う「型」という言葉は普通の言語の型と違うから、
Perlは型なし言語と言って良いと思う。
385 ：デフォルトの名無しさん：2001/06/22(金) 11:49: Perl6からね。（自分的には）良い感じに変わるんだよね。
386 ：363：2001/06/22(金) 19:26: 急浮上させておいて、自分で忘れてた。

う～ん、Ruby好きよ。
ってかネタ無い。逝きます。
387 ：デフォルトの名無しさん：2001/06/22(金) 20:04: 実行するまで型が分からんのが型無しだと解釈しとおりましたが…

コンパイル言語の場合どうやって実現してるのだか？
388 ：デフォルトの名無しさん：2001/06/22(金) 20:25: >>386
RTTI
389 ：デフォルトの名無しさん：2001/06/22(金) 20:25: >>387
390 ：デフォルトの名無しさん：2001/06/22(金) 20:44: カタナシダトプログラムしててわけわかんなくなるよ
ちょーむかつくー
391 ：デフォルトの名無しさん：2001/06/22(金) 20:52: >>385
やっぱりPerlの開発者たちも型有りの言語の方が
有用だって気づいたのかな？
楽しみだね。
392 ：デフォルトの名無しさん：2001/06/22(金) 20:56: >>390
型が無いせいじゃなくて
自分のノヲミツォが無いせいだろ。
393 ：390：2001/06/22(金) 21:01: >>392
どう考えてもわけわかんねーだろ
なにに使われてるかよくわからんし、
勝手に配列のサイズが変わってるし、エラーでねーし
394 ：デフォルトの名無しさん：2001/06/22(金) 21:11: Perl ファンのオレとしてはPerlが叩かれているのは痛い。
・型宣言した変数はその型に限定される。
・型宣言しなかった変数は型なし変数として扱われる。
・あるコマンドラインオプションを指定すると、型なし変数がある場合に警告を出す。

　というのが、いかにも折衷言語のPerlらしくていいと思うけど。
　つーか。その方が実行速度が上がりそう。
395 ：デフォルトの名無しさん：2001/06/22(金) 21:14: >>393
ハァ？
配列のサイズか変わるのは
動的型か静的型かとは関係ないだろ。
396 ：デフォルトの名無しさん：2001/06/22(金) 21:16: >>393
配列のこと以外は激しく同意。
397 ：デフォルトの名無しさん：2001/06/22(金) 21:54: 型の重力に魂を引かれてるね...
398 ：デフォルトの名無しさん：2001/06/23(土) 03:40: >>387
なにをコンパイルするか？という問題だ。

仕事で使ってる某社の独自言語なんだけど、
メソッドの内容はほぼCってかんじの言語で書き、
一方Interfaceはなにやら妖しげなしかけを使って
ほぼInterpreter状態でやっている。
なので変数の型を見てもObjectが何かは全然不明。

動的にメソッドディスパッチをして
(Network分散Objectなシステムなので、静的は無理なんだよな)、
いっぽう走るメソッド実装はCゴリゴリ
(分散したときのメソッド実装は、しょうがないから
それぞれのマシンに予めInstallしとけ、という仕様(笑))。

要するに入り口と中身の建て方が違うっていうだけ。
そういうのも可能だよ。
ん。良く知らぬがObjectiveCってのもソレなんじゃなかったか？
399 ：デフォルトの名無しさん：2001/06/23(土) 04:37: 型あり言語至上主義者は石頭の馬鹿。
ちょこちょこっと組むプログラムの場合
面倒くさいだけなのが分からんかボケ！
その点、型無し、型あり、ケースバイケースで
対応できるVBの柔軟さは素晴らしい！
400 ：デフォルトの名無しさん：2001/06/23(土) 04:43: oioi
VBはクソ
401 ：デフォルトの名無しさん：2001/06/23(土) 04:48: 判で押したように「VBは糞」としか言えない奴は
洗脳済み思考停止の阿呆
402 ：デフォルトの名無しさん：2001/06/23(土) 04:52: >VBはクソ
++;
403 ：デフォルトの名無しさん：2001/06/23(土) 04:57: VBはうんち
404 ：デフォルトの名無しさん：2001/06/23(土) 05:00: おまえの性格がうんちだ
405 ：デフォルトの名無しさん：2001/06/23(土) 05:18: >>399
ケースバイケースでVB使うのではなく、
ケースバイケースで使う言語を選べ。
VBはやっつけ仕事に最適。
406 ：デフォルトの名無しさん：2001/06/23(土) 06:00: >>400
バカ、あほ、糞、氏ね
プログラム技術板憲法第五条に
「VB厨は放置しましょう。」
と書いてあるだろうが！！
407 ：デフォルトの名無しさん：2001/06/23(土) 06:38: >>399
お・・・おいおい。
ＶＢでも型はちゃんとしとかないとダメだよ。
Option Explicitだよ。
408 ：378：2001/06/23(土) 07:35: >>380 >>381
では、そういうことで。でも、
今からこのスレッドは「動的型付け言語逝ってよし」になりました。
409 ：378：2001/06/23(土) 07:37: >>380 >>381
では、そういうことで。でも、
今からこのスレッドは「動的型付け言語逝ってよし」になりました。
410 ：399：2001/06/23(土) 08:42: >>407
だから、どんな場合でもOption付けるのが
四角四面の糞真面目馬鹿だっていってるんだよ。
小さいプログラムにゃウザイだけ。
なんでオプションなのかわかってねーよそれ。
411 ：デフォルトの名無しさん：2001/06/23(土) 08:45: >>410
馬鹿はおまえだ馬鹿市ね
412 ：デフォルトの名無しさん：2001/06/23(土) 08:47: >>410
あなたは小さいプログラムしか組んだことがないんですね。
だから気にならないだけですよ。
413 ：デフォルトの名無しさん：2001/06/23(土) 09:59: 型有りの言語でも型の宣言をする必要が無い言語は存在する･･
414 ：デフォルトの名無しさん：2001/06/23(土) 10:18: 状況に応じて、型ありになったり、型無しになったり
インタープリタになったり、コンパイラになったり、
ダイナミックリンクになったりスタティックリンクになったり
配列のインデックスが１から始まったり０から始まったり、
選択できるVBの柔軟性は素晴らしい。
415 ：デフォルトの名無しさん：2001/06/23(土) 10:25: >>413
でも関数型言語とかの型推論って
型の不整合が発見されても
実際のバグを探すのはすごく大変だよね。
型宣言を省略するんなら
それこそ小規模でないとやってらんない。
416 ：デフォルトの名無しさん：2001/06/23(土) 10:27: でも型有りの変数と無しの変数は混在させられないよね。
その点はPerlの方が柔軟。
宣言を必要に応じて使ったり使わなかったり出来る型推論
も柔軟かな。
417 ：デフォルトの名無しさん：2001/06/23(土) 10:28: >>415
は？何言ってるの？
型推論だろうが、そうでなかろうが、バグを発見
するのは同じだと思うけど？
418 ：デフォルトの名無しさん：2001/06/23(土) 10:49: >>417
1. バグってる型情報から矛盾が発覚するまでに
既に多くの型演繹がおこなわれている場合が多い。
2. 推論の過程が見えにくい。
3. 推論の順番によって結果が大きく異なる。

だから、特に高階関数を多用した時には
原因を追跡/特定しにくい。
特に宣言を省略するとグチャグチャ。
ちゃんと多相型で関数の型宣言をしたほうがいい。
419 ：デフォルトの名無しさん：2001/06/23(土) 10:59: >>415=>>418はMLを使ったことないに三億モナー
420 ：デフォルトの名無しさん：2001/06/23(土) 11:38: >>418
型推論は良く知らないが、まるで型無しの言語で実行時に型
の不整合が起こった場合の欠点のようだな。

普通はどの箇所で型の不整合が起こってるのかわかれば
たちどころにバグが発見できるものだが。
421 ：デフォルトの名無しさん：2001/06/23(土) 11:53: >>414
そこまで言うとDel厨房が対抗措置を発動するぞ(藁

ちなむとPascalは配列添え時範囲は任意の整数に出来る。
マイナスだってなんだって有り。配列宣言するときに好きに決める。

リンク形態はこのスレとは無関係。

インタプリタも無関係。実装部をどう扱うかと
Interfaceをどう扱うかは別問題なんだから、
実装部は爆速コンパイルが一番良いに決まってるし、
Interface部は混成(多態を使うために)でOK。

混成というか多態の仕掛けがあるので
「なかば型無し」なんだよOOP言語は。
そういう意味ではVBの素朴な戦略より
OOP言語のほうが少しマシ。

あと、あんな単純なやり方で切り替えができるのは
文法がそれだけ冗長というかまとまりが無いことの
裏返しじゃないのか？
422 ：418：2001/06/23(土) 12:40: >>419
MLはもう5年以上使ってないなあ。
最近の処理系じゃあ型のデバッグ環境が
しっかりしているってことでしょっかー？
知らんかったです。炒ってきます。
423 ：408 409：2001/06/24(日) 23:59: 2回書き込んでしまった。すみません。

>>380 >>381
型チェックはコンパイル時と実行時があります。
1 コンパイル時と実行時に型チェックする言語(静的型付け)
　　C++ Eiffel
2 実行時に型チェックする言語(動的型付け)
　　Smalltalk lisp scheme
3 コンパイル時に型チェックする言語(静的型付け)
　　C Pascal
4 型チェックしない言語
　　BCPL

また、型付けに強いと弱いがあり、スタティックキャストと関係があります。
C++ はスタティックキャストができるので、弱く型付けされた言語です。
Eiffelはスタティックキャストができないので、強く型付けされた言語です。
(ダイナミックキャストはできる)

なぜ、3は実行時に型チェックができないことが
あまり議論されないのだろう？
424 ：ラウンジマンセー！！！：2001/06/25(月) 00:01: >>1
どっちもありだと思うけどな。
ラウンジマンセー！！
425 ：>423：2001/06/25(月) 00:07: この議論はOOPLが前提になっているから３は論外ってことでしょ。

>また、型付けに強いと弱いがあり、スタティックキャストと関係があります。
この分類ってはじめて聞くんだけど出典希望。
型の強弱って変数に格納できる値の制限の強弱ってことだと思ってたけど。
426 ：423：2001/06/25(月) 00:28: >>425
「オブジェクト指向言語のはなし」
>型の強弱って変数に格納できる値の制限の強弱ってことだと思ってたけど。
はじめて聞いた。くわしく教えて。
427 ：デフォルトの名無しさん：2001/06/25(月) 00:37: http://saki.2ch.net/test/read.cgi?bbs=qa&key=993396409
428 ：デフォルトの名無しさん：2001/06/25(月) 00:37: >>425
OOPLが前提だとなんで3が論外なんだ？
429 ：>428：2001/06/25(月) 01:35: virtualによる多態性はlate bindingが前提だから。

３の範囲内でクラス実装するとしたら
virtual無しになってしまう。
430 ：デフォルトの名無しさん：2001/06/25(月) 02:47: Object Pascal は >>423 の (1) に入るんだよね？
431 ：426：2001/06/25(月) 03:06: >>425
その他いろいろな本に書いてある。
「CよりPascalの方が型付けが強い」とか。
432 ：デフォルトの名無しさん：2001/06/25(月) 19:06: >>425
型の強弱について知りたい場合は、ML 関連の本を読むとよくわかると思う。
433 ：デフォルトの名無しさん：2001/07/12(木) 17:14: Perlの型付けって、
my Dog $spot; # Perl5
my int $colors; # Perl6
とか
my INT @hit_count is dim(100,366,24); # Perl6
のこと?

どっちかっつーと実装ヒントっていう印象が強いんだけど。
型推論とかしないよね。
434 ：デフォルトの名無しさん：2001/07/18(水) 09:59: MLの型推論って、場合によっては非現実的なほど推論に時間がかかると
いうよね（めったに起こらないとは言うが）。

MLやHaskelみたいな強く型付けされた関数型言語が、異なる言語で書
かれたライブラリを利用する方法を持つなら、それがベストって気がす
る。（実行時効率を追求する場面では、C++なりEiffelなりのお世話に
なると思いますけど。）
435 ：デフォルトの名無しさん：2001/07/18(水) 11:15: 型推論って型の明示省けるっていう
シンタックスシュガー以上の意味はあるの？
436 ：デフォルトの名無しさん：2001/07/18(水) 14:28: >>435
自明な宣言を強制されるというのは、bookkeepingを人間に強制する
ということだから、好まれないのは明らかでは？

自明な型にまで宣言が要求されるのはコンパイラに負担をかけないた
め以外に理由があるの？
437 ：デフォルトの名無しさん：2001/07/18(水) 14:31: たとえば

int i = a.size()

みたいな式のintは、a.size()が整数を返すと決まっているなら
不要だよね。でもって、ここでint型に定義されたiを余所で別の
型が期待される文脈で使用していたら型不一致でコンパイル時エ
ラーにできるでしょ。つまりint型と明示的に宣言する必要はな
いわけですよ。
438 ：デフォルトの名無しさん：2001/07/18(水) 17:28: >>437
で、「var i = a.size()」の方が人間に親切なの？
プログラムって人間が読む/書くためのもんじゃないの？
439 ：デフォルトの名無しさん：2001/07/18(水) 18:14: 読む(直す)立場を重視するか書く立場を重視するかの違い
440 ：デフォルトの名無しさん：2001/07/18(水) 18:17: >>438
intと書きたいときは書けばいいの。それがML｡
ついでに言っとくと、MLでは一度定義した変数の値を
代入によって変更することはできない。それもバグの
ないプログラムを実現するために良い仕掛け。
441 ：デフォルトの名無しさん：2001/07/19(木) 00:23: 型推論ってのは、動的型付け言語であっても、不要な実行時型判定をしてる
部分をバッサリ取っ払うとかの用途で有効だと思う。
最適化の無いインタプリタではモロに速度に影響するでしょ。
442 ：デフォルトの名無しさん：2001/07/19(木) 00:27: >>439
>書く立場を重視するか
おおっ、perlとの意外な接点が!!
よってPerl=ML=糞言語
443 ：デフォルトの名無しさん：2001/07/19(木) 00:41: >442
きみ、理解してないと思う。
444 ：デフォルトの名無しさん：2001/07/19(木) 07:50: >>441
それはコストがかかる割に効果があがらないんじゃないかなあ。
ソースコード上に型不一致があると「実行時に型を決定」し、ソース
コード上に型不一致がないと「コンパイル時に型を決定」するという
話でしょ。そこまでやるなら、コンパイル時に型を決定すべき（つま
りコンパイル時に型チェックする）変数・関数・式はそれと宣言させ
た方が良いってことになる。

たとえばObjective-Cの場合、型チェックを実行時に遅らせるときに
はid型を使えば良く、コンパイル時に型チェックさせたいときにはク
ラスを特定する変数宣言を使えば良い。
445 ：デフォルトの名無しさん：2001/07/19(木) 09:08: ためになるので、あげ
446 ：デフォルトの名無しさん：2001/07/19(木) 09:23: 逝ってよしというやつが逝ってよし
447 ：デフォルトの名無しさん：2001/07/19(木) 23:18: だれか型推論するコード書いてくれ。
448 ：素人：2001/07/20(金) 01:53: なんか、最新のPerlって、Cソースコードを埋め込んで実行時にコンパイルって
いうのができるとかなんだとか

もう汚れキャラで開き直ってるんだなあって思った。
449 ：デフォルトの名無しさん：2001/07/20(金) 02:02: 外部のＣコンパイラ起動すんの？>448
そんなのPerlじゃなくてもできるけど。
それともC->Perlトランスレーターとかかい？
450 ：デフォルトの名無しさん：2001/07/20(金) 10:21: Perl6はCにトランスレートしたときの効率を
結構重視していると思われ。
451 ：デフォルトの名無しさん：2001/07/20(金) 14:11: >>448, 449
use Inline;のことかな。
スクリプトを初めて実行したときに、うめ込まれたCコードをコンパイルして
.so(または.dll)を作成する。

二回目以降は、(ソースコードのMD5ハッシュが変わってなければ)
以前にコンパイルした.soをロードして使う。

どちらかと言うと、今までXSとかSWIGとかでガリガリ書いてた
C実装のモジュールを作りやすくした仕組と言った方が正しい。
Makefile.PLを書かなくていいとか、Perlソースと一元管理できるとか、
そういうことがメリットだと思う。

> もう汚れキャラで開き直ってるんだなあって思った。
粋狂な人がいればそういうことをするモジュール(Inline.pm)
「も作れる」ということだね。むしろ懐の深さ。
452 ：shige：2001/07/20(金) 14:31: ﾌﾟﾌﾟﾌﾟﾟﾌﾟﾌﾟ必死だな（ﾜﾗ
Ruby以外の言語は糞。
453 ：デフォルトの名無しさん：2001/07/20(金) 16:49: >Perl6はCにトランスレートしたときの効率を
>結構重視

ruby作者も言っているが、
動的な要素の多いScript言語と静的なCとじゃ
うまく噛み合わないことが多いはずだぞ。

>>451
その程度のことしかしないなら、他の多くの言語でも出来る。
VBですら出来るだろうな。
少なくともPerlの懐を認める論拠にはならん。
尤も浅いとも言明できぬが。
454 ：デフォルトの名無しさん：2001/07/20(金) 21:37: >>440
つまりMLは書くための言語なのね。
「読むため」の比率が高い方がいいという考えもあり得るヨ。
455 ：デフォルトの名無しさん：2001/07/20(金) 23:24: >>454
はあ？
なんか全然わかってないね。MLで書かれたプログラムを多少なりとも
読めば、きわめて「読みやすい」言語だってことがわかると思うがな。
何のために「参照透過性」にこだわってると思ってるの？　プログラ
ムを読むときに各変数の値がどうなっているか「追いかける」必要を
なくすためでしょ。

たとえばフィボナッチ数を計算するコードは次のように書ける。

fun fib 0 = 1
| fib 1 = 1
| fib n = fib (n-2) + fib (n-1);

どこにも型宣言は出てこないが、0や1が整数である以上、nも整数なのだ。
（整数は整数同士でないと足し算も引き算もできない）
fib 0の場合、fib 1の場合、fib nの場合とで「パターン」で分けてコー
ドを書けるのもきわめて明快だと思うがな。
456 ：デフォルトの名無しさん：2001/07/20(金) 23:32: >>455
0や1なの? 2や1じゃなくて。
457 ：デフォルトの名無しさん：2001/07/20(金) 23:54: >>455
だから、そういう地べたのデータ構造扱うのは別に
どうでもいいよ。なんか大きなプログラム組むので、
抽象データ型とか定義しまくったとするじゃない
(MLでできるのは知ってる)。で、それらを利用する
コード書いてるとき、この引数はこの型とか考えて
宣言書いて、構造ができてきたら実装書いて、とか
いう順で書かないのかな。これ疑問その1。

疑問その2として、実装からバリバリ書いて型推論
あるから自分は宣言つけなくていいと思ったとして、
それを読まされる人は書いた人じゃないわけだから、
読むのがつらいんじゃないかな？それを指して「書く
人に寄ってる」と表現するのは正しくないと思う？

やらない？型推論
458 ：デフォルトの名無しさん：2001/07/21(土) 00:38: >>457
MLは関数型言語だから、これこれの型の引数をとってこれこれの型の
戻り値を返す関数を……という発想が先行する。プログラムを関数の
集合に還元し、個々の関数をひとつひとつボトムアップ的に実装する
ことでプログラムを実現するので、先に抽象データ型を定義しまくる
という発想にはなりにくいと思う（オブジェクト指向じゃないからね）。

引数の型にしても、リストやタプルが強力だから（LISPでは何でも
リストで解決するし、それで不自由はないわけです）、やたらめった
ら新しいデータ型を定義しないと困るわけでもない。むしろ、特定の
処理だけに使う関数を定義するのではなく、より抽象的な汎用性の高
い関数を定義することに関心が向かうはず。

たとえばC++でもテンプレートってあるでしょう？　あれみたいに任
意の型に対して処理を行う関数を書くことができるし、LISPでいう
mapみたいな処理を使って手続き抽象を行うこともしばしばだから、
457さんの心配しているような世界とは根本的に違うんじゃないかと
思う。
459 ：デフォルトの名無しさん：2001/07/21(土) 00:40: >>456
1や2と書いた方がわかりやすかったね。
でも、0や1でも正しいのです。
整数を引数にとって整数を返す関数定義であることは1行目で自明なので、
他の行にそうではない定義があれば型不一致のコンパイル時エラーになります。
460 ：デフォルトの名無しさん：2001/07/21(土) 00:46: つーか、MLは数学的定義とプログラムコードが対応しやすいように
設計されてて、MLのコードを見れば、その数学的な意味がつかみや
すいようになっているわけ（MLプログラマはそのように意識してコー
ドを書くということでもある）。

（たとえば）Cのコードから、その数学的な意味をイメージすること
は困難である場合がほとんどでしょ。そういう意味では、Cに代表さ
れる手続き型言語はどれもこれもコメントなしには読んでられない
わけよ。
461 ：デフォルトの名無しさん：2001/07/21(土) 01:51: プログラミングを関数書きにmapする、という発想が
今なにかソースを書こうとしてる自分にとって
自然な発想かどうか？という問題だな。

>やたらめったら新しいデータ型を定義しないと困るわけでもない。

OOPでいえばBuilderパターンって奴ですな。
単純なObjectをかき集めて大きな複合Objectを作る、
という手順を書くというパターン。

まぁ定義というほど大げさなもんじゃなくて、
prototype型OOPみたいな奴だと
かなりLispに近い世界だと思うが、どうか？
クラスが無いから、インスタンスをコピるか
属性(大抵は参照)をいじるか、どっちかしかできない。
CAD/CDRの世界と殆ど同じだと思う。

逆にいうとそういうBuilderを運良く(わら)1つにまとめる
ことが出来たならば、それをClassというものにする
ことが出来る言語、ってのもある、というだけのことだ。

#C++は痛いよ。OOPの本質を考える暇を与えてくれないから。

>たとえばC++でもテンプレートってあるでしょう？

C++のアレは、任意の型といっても、
構造かまたはInterface(字面の)が
事前に決めといた奴であることが前提なんで、
あんまり高度(抽象度の高い)なことは出来ないと思われ。

>Cに代表される手続き型言語はどれもこれもコメントなしには
>読んでられないわけよ。

それは変な主張だな。任意(?)の言語のソースを数学に「おとす」ことが
可能でありかつ人体にとって自然だ、という前提が必要だろう。
でもそれは常に言える前提か？
俺ぁ数学の式にこそコメントを書きたいと思うことが有る(わら
俺の体にはあれは自然だと感じられないので。

蛇足だが、プログラミングにおいて短い変数名を
妙に愛する奴がたまにいるが、あれは数学畑から
持ちこんだ悪い病気だと思う。
462 ：デフォルトの名無しさん：2001/07/21(土) 02:00: >>459
てことは、全パターンひっくるめて型が推論されるわけ?
463 ：デフォルトの名無しさん：2001/07/21(土) 08:35: >>462
まさにそのとおりです。
関数は意味のある戻り値しか返さず、たとえば引数が定義域外だった
場合などには例外を投げます。逆に言えば戻り値が返ってくるかぎり
は確実に有意味であり、型一致も保証されているのです。
464 ：デフォルトの名無しさん：2001/07/21(土) 08:43: >>461
そうねえ……バグのないプログラムを指向していくと、プログラムの
仕様を形式的に定義することに行き着くと思うんだけど、形式的な仕
様定義はどうしたって数学的な記法・発想法に基づかざるを得ないと
思うんだね。

それをより抽象度の低い（具象性の高い）方法で実現しているのが、
Eiffel流のAssertion（事前表明、事後表明による、programming
by contract）もひとつの方法だよね。

> 蛇足だが、プログラミングにおいて短い変数名を
> 妙に愛する奴がたまにいるが、あれは数学畑から
> 持ちこんだ悪い病気だと思う。

形式主義の立場からすれば、任意の型について有効な関数は、無意味な
変数を象徴的に使うことが本質的だと思われ。
465 ：デフォルトの名無しさん：2001/07/21(土) 08:58: 型チェックをコンパイラにやらせるというのは、
1) 実行時に型チェックすると実行時効率が落ちるから
2) コンパイラで検出できるエラーはコンパイラに検出させるべきだから
ということに理由があるけど、Javaなんかはキャストを多用せざるを得
なくてウザいってのはあるよね。

たとえば、動物族を格納するコンテナがあるとして、そこに格納された
動物の正確なクラスを実行時に調べて、そのクラス別に処理を変えたい
ような場合（その動物がライオンであれば吠えさせ、サイならば突進さ
せる、みたいな処理）はキャストがどうしても必要になる。でも、その
キャストって本質的なのかなあって気がするときがしばしばなのよね。
実行時にクラスを調べて、キャストしてからクラス別の処理に入るみた
いな仕組みは動的な関数ディスパッチより、かえって効率落としてるん
じゃないかって思うんだけど……。

Objective-Cのように実行時に関数ディスパッチすることを選択できれ
ばキャストは不要なのにって思う。
466 ：457：2001/07/21(土) 13:53: >>458
分かりました。オブジェクト指向じゃないのなら私の知らない
(というか普段使わない)世界なので引っ込みます。

オブジェクト指向で大きいもの作るなら「たとえ型推論があった
としても」明示的な型宣言をする方がよいと考えていますが、
それは関数型パラダイムとは別のオハナシ、ということなのです
よね。

>>465
それは、「ライオンなら吠え、サイなら突進」という動作に対応
するメソッドを定義して、ライオンとサイで別のコードを貼り付
けておき、dynamic dispatchに仕事をさせるべきなのです。Java
でキャストを必要とするのはむしろ、「生き物型」の変数に「動物」
を(サイでもライオンでも)入れてあって、それをまた「動物」と
しての扱いに戻したいといった「視点の切り替え時」じゃないかな。

で、Javaでこれが多用されるのは、型パラメタがないためコンテナ
には全部Objectとして入れて、出して来たらまた元の型にキャスト
し戻す、というのがやたら多いせいでしょ？
467 ：デフォルトの名無しさん：2001/07/21(土) 21:13: >>466
吠えるのと突進するのを同名のメソッドとして定義するってこと？
468 ：デフォルトの名無しさん：2001/07/21(土) 22:38: >>467
「敵対行動をとる」といったような一般化されたメソッドを考え、
ライオン⇒吠える、サイ⇒突進、
といった具合いに特化したメソッドで実装する。

このメソッドを利用する側からみれば、
テンプレートメソッドパターンということになるのでは。
でも、OOSEに説明されているようなメソッドスペシャリゼーションの
問題が浮上してきそうではありますな。
469 ：デフォルトの名無しさん：2001/07/22(日) 09:06: >>468
なるほど...でも、ちょっと苦しくない？
敵対行動が一種類しかとれないとは限らないし（クラスによって、
特化したメソッドの種類と個数が違うなんてことはありがちでし
ょ？）。

Javaって、関数ディスパッチを実行時に遅らせる方法ってあるん
だっけ？
470 ：デフォルトの名無しさん：2001/07/22(日) 12:47: 抽象データ型の定義の際に、定義域を明示的かつ簡便に定義できる
言語ってあります？あったらいいな。

int height(min: 100, max: 200)

みたいにすると、heightは100以上200未満の整数しかとらない、みたいな。
現状ではセッターを定義して手作業でチェックしないといけない言語ばっかり
なんですけど、すごく頻繁に使いますよね？
471 ：デフォルトの名無しさん：2001/07/22(日) 13:04: >>470
Pascalがある。

type height = 100..200;

と定義すればOK。
472 ：デフォルトの名無しさん：2001/07/22(日) 13:16: >>470
Adaがそうです。
タイプを定義するときに範囲を指定できます。

    type HEIGHT_TYPE is range 100 .. 200;
とか、
    subtype HEIGHT_SUBTYPE is INTEGER range 100 .. 200;

とかいった具合いになります。

>>470の関数宣言の例
> int height(min: 100, max: 200)
だと、

    procedure HEIGHT(X: in HEIGHT_SUBTYPE);

といったところになるでしょうか。

163 KB

■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る全部前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)