型なし言語逝ってよし

■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■

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