東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

interfaceに物申す(3)

interfaceに物申す のコメントでちらっと出てきた NVI について。

NVI:non-virtual interface : 非仮想インタフフェイス
そこそこ名の通ったイディオムかと思うです。

class なにか {
public:
  virtual void なにかする() { ... }
};

じゃなくて

class なにか {
public:
  void なにかする() // non-virtual
    { あーする(); こーする(); }
protected:
  virutal void あーする();
  virtual void こーする();
};

てなスンポーで、公開メソッドをvirtualにしないってスタイル(イディオム)。
導出クラス側では直接 なにかする() を再定義すんじゃなく、
あーする() や こーする() を再定義するなり再利用するなりせぇ、と。

こうしておけば、後日なんらかの理由で なにかする() のインタフェースが変更に
なったとき、再定義された なにかする() の変更をこいつの導出クラス全員に
お願いして回らんでええわけや。

C++の場合、再定義させないkeyword: finalやsealedに相当するものを
持ち合わせてないのでその代わり、の意味もありますです。

投稿日時 : 2009年1月7日 9:24

コメントを追加

# re: interfaceに物申す(3) 2009/01/07 10:24 インドリ

この話題ボクもずっと気になっていたピヨ。
現在のアクセス修飾子は少なすぎピヨッ!
仮想権限とコード範囲の概念を取り入れるべきピヨ。
私用する側は見えない部分と、拡張する人には見える部分とか・・・

# re: interfaceに物申す(3) 2009/01/07 10:43 επιστημη

ごめんわかんね。C#(.Net)でのおはなし?

> 使用する側は見えない部分と、拡張する人には見える部分とか・・・

protected じゃなくて?

# re: interfaceに物申す(3) 2009/01/07 11:01 インドリ

>protected じゃなくて?

うん♪そうです。
επιστημηさんが既に指摘しているけども、コンポーネント開発者が必要なインタフェース部分と、コンポーネント利用者が必要なインタフェース部分が違うとボクも思うピヨ。
なので、少なくとも作る側/使用する側の区別ぐらいは必要で、もっと言えば適切な認証を得た人だけがコードを見て拡張できる仕組みなどのより深い「アクセス修飾子」が必要とボクは思うんだ。
あと細かいところを言えば、オーバーライド時に始めに呼ぶのか最後に呼ぶのかを適切に判断するためのメタ情報とかまだ色々アクセス修飾子に必要だと思います。

# re: interfaceに物申す(3) 2009/01/07 11:09 επιστημη

> 認証を得た人だけがコードを見て拡張できる

ここでの"人"とは擬人化されたクラスとかじゃなくて、
ホントの人(プログラマ)?
だとするとそれは言語のアクセス修飾子でどーのこーのするこっちゃなく、
開発リポジトリのやることちゃいます?

> オーバーライド時に始めに呼ぶのか最後に呼ぶのか

ごめん、わからんす。

# re: interfaceに物申す(3) 2009/01/07 12:56 aetos

> オーバーライド時に始めに呼ぶのか最後に呼ぶのか

派生クラスで関数をオーバーライドしていて、その中で基底クラスの実装を呼ぶ必要がある時、派生関数の最初に呼ぶのか、最後に呼ぶのかということでしょうかね。
ただ、最初か最後の2択とも限らないと思いますが。

# re: interfaceに物申す(3) 2009/01/07 13:20 επιστημη

そゆ意味? だとしてもわからんす。
なんでそんなのを言語がサポートせにゃならんのだろ。

class なにか {
public:
 void なにかする() {
  事前にすること();
  いろいろ();
  途中ですること();
  あれこれ();
  事後にすること();
 }
protected:
 virtual void いろいろ();
 virtual void あれこれ();
};

としておいて、導出側で いろいろ()/あれこれ() のみを再定義すれば
事前に/事後に/途中ですることを基底側で強制できるしょ。
# まさしくNVIなんだが。

「アクセス修飾子として必要」な理由が想定できません。

# re: interfaceに物申す(3) 2009/01/07 16:16 インドリ

>「アクセス修飾子として必要」な理由が想定できません。

何故欲しいのかと言うと、このてのメタデータがあれば、より自動化できるようになるし、多くのメタ情報を含んだ方が開発環境のパワーアップと、保守作業が効率化すると思うからだピヨ。

# re: interfaceに物申す(3) 2009/01/07 16:24 επιστημη

だからぁ、それは"メタデータ"っしょ?
"アクセス修飾子"と"メタデータ"は別モノちゃうの?

# re: interfaceに物申す(3) 2009/01/07 16:42 インドリ

アクセス修飾子はコードの可視性についてのコンパイラ用メタデータだと考えていたので、こういった発想が出てきました。
C#の属性とかC++のコンセプトの様に記述すればいいのかもしれないけども、標準のアクセス修飾子の方が見た目が美しく意味的にも分かりやすく、コード解析がやり易いかなと・・・
あと、一層の事アクセス修飾子を増やした方が簡潔で美しい記述になると考えました。
現在のコードベースのアクセス修飾子の表現能力に限界を感じませんか?
#感覚論で済みません。

# re: interfaceに物申す(3) 2009/01/07 17:00 επιστημη

絶対反対。
コード"解析"に必要なメタデータてことは処理系依存てことでしょ。
コード"生成"に必要なデータじゃないんだから。
そんなもんをどこぞのメーカで勝手に標準キーワードにされちゃたまらんし、
キーワード増えすぎて破綻すんじゃないかな。

> 現在のコードベースのアクセス修飾子の表現能力に限界を感じませんか?

感じることもありますが、闇雲に増やせばいいってもんでもなかろうな、と。

# なんか噛み合わんなー
# アクセス修飾子 は メタデータ の一種かも知れんけど 同じもの ではないよね。
# インドリさんは 同じもの として語ってる?

# re: interfaceに物申す(3) 2009/01/07 17:12 aetos

分かってるかも知れんが、メソッド名の前に書くやつは(戻り値の型を除いて)全部「アクセス修飾子」とは呼ばないよ。

# re: interfaceに物申す(3) 2009/01/07 17:26 インドリ

>感じることもありますが、闇雲に増やせばいいってもんでもなかろうな、と。

その考えは正しいと思います。
言われてみれば、確かに弊害が大きくなりそうです。
ボクが求めていたのは、より開発工程全般に、コントロール出来る事なんです。

ボクが想像していたのは、現実のアクセス可能性と連動して・・・
設計者が意図した以外の使い方をしたらコンパイルエラーが生じるとか
その逆にプログラマがアクセス修飾子を変更したらそれに連動して設計図が変更される(設計ミスのチェック)とか
開発環境にインテリジェンス機能を持たせて、必要で無い冗長なインタフェースを表示しないAnd触らせないとか・・・

つまり全ての開発環境により生産性を高める指定をしたいわけです。
脱・テキストファイルベース開発です。
#LISP的思考に近いかな?
ただ今から思えば、マイナス面を考えると間違っていたのかもしれません。

# re: interfaceに物申す(3) 2009/01/07 17:33 インドリ

aetosさんへ
ごめん。アクセス修飾子以外も含んでいっているピヨ。
現在の予約語はあまりにテキストファイルベース過ぎるから、より生産性をや表現力を高める工夫をした方がいいと言いたかったんだ。

# re: interfaceに物申す(3) 2009/01/07 17:41 επιστημη

> 脱・テキストファイルベース開発です。

えー!? それを持ち出すならアクセス修飾子云々に絡める必要ないやん。
テキストがソースコードのすべてじゃないんでしょ?
だったらテキストじゃないとこに思う存分メタデータでもなんでも詰め込めばいい。

....やっぱ噛み合わんぞ


# re: interfaceに物申す(3) 2009/01/07 17:44 επιστημη

> アクセス修飾子以外も含んでいっているピヨ

うわー..."俺語"でやられちゃ議論が成立せんわ。

# re: interfaceに物申す(3) 2009/01/07 18:39 インドリ

アクセス修飾子以外も含んでいっているピヨ

これについては、ついつい書いてしまったと言う事ピヨ。だから前提にしては居ません。
余計な雑音混じってごめん。


>えー!? それを持ち出すならアクセス修飾子云々に絡める必要ないやん。

ちょっと大げさだったので、もっと堅実なところを言うと、Internet private local publicとかそんなぐらいは欲しいなーという事ピヨ。

# re: interfaceに物申す(3) 2009/01/07 18:44 インドリ

internet private local public
って言うのは、インターネット経由ではアクセス出来ず、ローカルならアクセスできるという意味ピヨ。
こういったアクセス修飾子は、セキュリティ的にも必要だと思うんだ。

他には権限が低いオブジェクトから実行できない
adminもしくはrootとか
より局所的にしか実行できないメソッドとか・・・
色々「アクセス」にも指定するべき事があると思うピヨ。

# re: interfaceに物申す(3) 2009/01/07 19:11 aetos

caspol とか ACL とか、いろいろ制御する方法はあると思うけど、言語がサポートしなきゃだめなん?
個人的に、言語はすっきり、ライブラリでガッチリってのが好きなんですが。

あとは例えば、「インターネット経由でのアクセス」って何? とか。
インターネット経由でデータを取得しているアプリからプロセス間通信で呼ばれてそのデータを受け取るオブジェクトは「インターネット経由でアクセスされている」と言えるのか?
言えるとすれば、その状態を確実に伝播させるにはどうするべきなのか?

他には、「ユーザーが Administrator グループに属しているかどうか」を判断して何か処理をすると、ロクなことにならない、とか。
このへんはちゃっぴさんに語らせると熱いと思う。

# re: interfaceに物申す(3) 2009/01/07 19:28 インドリ

例えが悪かったとは思うけど、現在のアクセス修飾子で本当に満足しているのかな?
アクセスってそんなに単純なものだとはボクは思わないピヨ。

>caspol とか ACL とか、いろいろ制御する方法はあると思うけど、言語がサポートしなきゃだめなん?
個人的に、言語はすっきり、ライブラリでガッチリってのが好きなんですが。

多層防御の考えから必要だと思うピヨ。
コードレベルの防御も必要だと思うピヨ。


>他には、「ユーザーが Administrator グループに属しているかどうか」を判断して何か処理をすると、ロクなことにならない、とか。

これについてはその面はあると思うけども、要するにボクが言いたいのは「アクセス」ってそんなテキストベースな概念でいいん?
という事に尽きるピヨ。


今回の例についてはNVIがあったからいいものの、そんなにすっきりしない事なんて現場ではざらにあるよね。
そんな表現能力の低い状態で満足するの?
ボクは満足できないピヨ。
昨今のプログラム言語は機能を増やす方向で言っているけど、既存の概念を見直さなくていいのかな?

# re: interfaceに物申す(3) 2009/01/07 19:36 p

>既存の概念を見直さなくていいのかな?

既存の部分を変更なんて恐ろしくてできない・・・ガクガクブルブル

# re: interfaceに物申す(3) 2009/01/07 19:49 インドリ

ちなみにアクセス修飾子の不十分さについてはプログラミング.NET Freamworkでも言及されているピヨ。

# re: interfaceに物申す(3) 2009/01/07 20:09 επιστημη

> internet private local public

分散オブジェクトのおはなし?
外に見せるメソッドのみをinterfaceで公開する
だけのこととちゃう? CORBAとかWCFみたく。

# なんかあれもこれも詰め込んでオナカ壊してない?

# re: interfaceに物申す(3) 2009/01/07 20:39 aetos

> これについてはその面はあると思うけども、要するにボクが言いたいのは「アクセス」ってそんなテキストベースな概念でいいん?
> という事に尽きるピヨ。

まったくその通りで、だから CAS とか ACL とかあるでしょうと。
「アクセス」ってプログラミング言語がカバーできるような単純なものでいいん? と返しときます。
ちゅーかアクセス修飾子はセキュリティを目的としたものじゃないし。

>>> 脱・テキストファイルベース開発です。
>> えー!? それを持ち出すならアクセス修飾子云々に絡める必要ないやん。
> ちょっと大げさだったので、もっと堅実なところを言うと、Internet private local publicとかそんなぐらいは欲しいなーという事ピヨ。

結局テキストベースなのかそうじゃないのかどっちなんだ。

# re: interfaceに物申す(3) 2009/01/07 20:43 インドリ

>なんかあれもこれも詰め込んでオナカ壊してない?

そうかもしれない(笑)
こういった話題は具体例が書きにくいピヨ。
仕事の関係上、設計から実装するにあたって、不都合が一杯あるけど、秘密保持契約を結んでいるからいえないし・・・
自分の研究内容もいなえないし・・・
特にかく、アクセス修飾子の表現力不足がこの手の問題を生み、それが開発生産性を下げている事を指摘したいんだけど、直接的にかけないから良い例が思い浮かばないピヨw
なんにせよ、「アクセス」ってもう一度見直すべき概念だと思うピヨ♪
オブジェクト指向分析によりテキストベースを超えた問題領域が浮かび上がってくるから、昨今のプログラミング言語のアクセスの表現力不足が非常に悪影響を及ぼしていると感じるピヨ。
あと、同様の問題で動的モデルや並列表現が不足しているのは有名な話しだし♪
これからのプログラミング言語の発展を楽しみにしているピヨ♪

# re: interfaceに物申す(3) 2009/01/07 20:59 インドリ

>結局テキストベースなのかそうじゃないのかどっちなんだ。

えっと、ボクが言いたいのは「アクセス修飾子」なのにテキストベース過ぎるからもっとアクセスの概念を洗練して見直すべきと言う事ピヨ。
ボクにとってのプログラミング言語とは思考ツールであり、ネットワーク構築とかデーターベース構築とかの部分は別にして、妥協無く無限に進化しなければならないものだと考えているピヨ。
思考ツールが思考を制限するのはおかしいと思うピヨ♪

# re: interfaceに物申す(3) 2009/01/07 23:28 ちゃっぴ

どうやって実現するの?

ちゃんとやるならすべての OS に共通した仕様を適用させる必要があると思います。

# re: interfaceに物申す(3) 2009/01/08 0:26 επιστημη

...やっぱりわからん。

- "アクセス修飾子"はvisibility/accessibilityを
  制御するもので、セキュリティやネットワーク越し
  云々は別に扱うべきもんだろ。
- テキストベースであることと何の関係があるんだ?
- 言語(=思考ツール)が思考を制限するのはアッタリマエちゃうか?
 なんもかんもと欲張るとオナカ壊します。
 適材適所を勘案し、適切なツールを選ぶのが正解と思う。
 複数の言語で連携プレイできるんだし。

# re: interfaceに物申す(3) 2009/01/08 0:43 どっと納豆

思い切り今さらですけど、やっぱりメタデータじゃないかなあ。
CLRにもっともっとがんばってもらえばなんとかなるかも。

もうアクセス修飾子はクラス内に書かない。
グラフィカルなエディタで、メンバやクラスや名前空間の関係を定義する。
アクセスでもセキュリティでも検証でも例外でも、
なんでもかんでもこっちにもってきちゃう。
もはや保守や再利用より書き直したほうが速い世界。
しょぼいスキルでも、一定以上の品質が保証されてしまう世界。

もしマイクロソフトががんばってこういうものを作ったら、
みんな使わないのかなあ。

# re: interfaceに物申す(3) 2009/01/08 2:21 あ~んてっこ

りんごの話にもどると
そもそも
りんごオブジェクトに
behavior
があるからおかしくなってんじゃないの?

# re: interfaceに物申す(3) 2009/01/08 7:05 επιστημη

↑それでどうおかしくなってんの?

# re: interfaceに物申す(3) 2009/01/08 8:32 インドリ

ボクがおかしいと感じている点は、オブジェクト指向ってメッセージ通信だから、メッセージのアクセス特性を記述できる方がいいのに、テキストベースなアクセスしか考えられていない点ピヨ♪
それにコードブロック的なアクセス修飾子はそもそも不十分で、クラスのアクセス特性・メソッドのアクセス特性・プロパティのアクセス特性(オプション)などの特性を一つのアクセス修飾子に共通するのも表現力不足ピヨ。
いい例が思いつかないけど、
関連オブジェクトに関するアクセス特性、
一時オブジェクトに関するアクセス特性、
動的モデルにおけるアクセス特性。
・・・・
とか様々な表現が出来てしかるべきだし、セキュリティ的に考えると、アクセスできるもの全てをコントロールする手段が必要となってくるピヨ。
セキュリティ的考えで言えば、「コードがお留守だぜ!」は避けたいピヨ。
他にも分散オブジェクトや並列オブジェクトももっと簡単に記述したいピヨ。
基幹系業務システムとかを作っている時何時も困っているピヨ。
この違和感をなんと表現すればいいのだろう?
オブジェクト指向を非オブジェクト指向言語で実装しているような「無理やり感」のようなものを感じてしまうピヨ。
より大規模システムの構築を最適化する言語を考えた場合アクセス特性の記述は不可欠だと思うピヨ。
現在は一応属性とかで記述しているけども汚い!
ああ、汚いコードは嫌いピヨ。
#この辺はただの価値観です
複雑なシステムとなると5つぐらい属性を書かなければならない。
リフレクションのパフォーマンス劣化が心配ピヨ!

# re: interfaceに物申す(3) 2009/01/08 9:20 インドリ

誤解されそうなので追記します。
ボクが言っているのは「全ての言語」ではないピヨ。
ボクが不満に感じているのは、多くのプログラミング言語が既存の概念を継ぎ足して、機能を追加するやり方ピヨ。
機能を何でも追加したらいいわけはなく、より適切なデザインの元作られたコンパイラが製作されるべきだと思うピヨ。

# re: interfaceに物申す(3) 2009/01/08 9:40 επιστημη

言わんとするところはわかってきたなり。
関係のない「メタデータ」を持ち出したり、
本来の「アクセス修飾子」を勝手に拡大定義してたり、
そんなんが話をこじらせてたわけね。

で、そーゆーおもろいネタをコメントに埋没させるよか
トラックバックかまして自身のblogで展開してくだせ。

# re: interfaceに物申す(3) 2009/01/08 10:04 επιστημη

> 機能を何でも追加したらいいわけはなく

その論でいくとC++はサイテーの言語だな(枯藁

> より適切なデザイン

そんなのが機能追加なしにいきなりできるわけねーw

# re: interfaceに物申す(3) 2009/01/08 11:26 ちゃっぴ

> そんなのが機能追加なしにいきなりできるわけねーw

全部いったんぶっ壊して全部一から作り直すということじゃないですかね。言語だけでなく OS も含めて。
じゃないとできないでしょうから。

# re: interfaceに物申す(3) 2009/01/08 11:33 επιστημη

> 全部いったんぶっ壊して全部一から作り直す

今日書いたコードが明日にはゴミになる言語なんか
こっちから願い下げっすー♪

# re: interfaceに物申す(3) 2009/01/08 16:29 インドリ

C++は最高の言語だと思っているピヨ♪
昨今の関数系機能の追加ブームはいいんだけど、そんなに追加せずに、アクセス修飾子といった既存概念の落ち葉拾いはするべきピヨ。

# re: interfaceに物申す(3) 2009/01/08 16:53 επιστημη

> C++は最高の言語だと思っているピヨ♪

なんでぇ?
アナタが不満に感じている
「既存の概念を継ぎ足して、機能を追加するやり方」
の最たるもんやで。

加えてCから受け継いだ汚らしい部分が山ほどある。
下方互換性を重視するから拭き清めるのが困難。

過去のしがらみにまみれ汚いことこの上ないC++を
"最高の言語"と評するの?

× 落ち葉拾い
○ 落穂拾い

# re: interfaceに物申す(3) 2009/01/08 18:12 インドリ

http://indori.blog32.fc2.com/blog-entry-625.html
に纒を書いてきたピヨ♪
興味ないかもしれませんが、一応見て欲しいな♪


>過去のしがらみにまみれ汚いことこの上ないC++を
"最高の言語"と評するの?

それは、色々理由があるけども、大きな理由はネイティブコンパイラだからピヨ♪
何でも仮想マシンにすればいいってものじゃない!
ネイティブ言語が無くなればどうやってOSをつくるのでしょう。
ボクはそんな「皆一緒に仮想マシン運動」は大嫌いなんだ。
あと、継承・テンプレート・多重継承・コンセプトが最高♪
C++は穢れた部分にうんざりする時もあるけど、汚れ役もこなすから大好きピヨ♪
C++の存続が少し危ない気もするけど、そんな言語がもしWindows上からきるのならば、ボクは迷わずBSDかLinuxへ飛び立つピヨ。

# Access を制御するものはどこに置くべき? 2009/01/09 0:21 ちゃっぴの監禁部屋

Access を制御するものはどこに置くべき?

# re: interfaceに物申す(3) 2009/01/09 0:53 あ~んてっこ

状態しかないオブジェクトもあるわけで
りんご
なんてそんなものでしょ。

# re: interfaceに物申す(3) 2009/01/09 1:09 επιστημη

↑ごめんわからん。

- Colorを返すメソッド 色() のどこがダメなんすか?
- りんごオブジェクトに behavior があることでどこが
 どうおかしくなってんです?

# re: interfaceに物申す(3) 2009/01/09 10:52 επιστημη

> 大きな理由はネイティブコンパイラだからピヨ♪

ちょっとマテ。
それは処理系matterであって言語とは関係ねぇだろ。

# re: interfaceに物申す(3) 2009/01/09 17:01 インドリ

>それは処理系matterであって言語とは関係ねぇだろ。

でもC++が仮想マシンを望んでいるとはとても思えないピヨ。
それに万が一仮想マシンだとしても、既に書いてあるけども、テンプレートとか色々好きピヨ♪
#とはいえ、C++が仮想マシンと言うのはいただけない
それから不思議な点が一つあるピヨ。
無差別に機能を追加した言語で無いことは、D&Eの監修をしたεπιστημηさんならば知っているのに何故そんなことを?
さては試しているピヨねw
ボクはD&Eを読んで言語設計も含めて好きだと思っているピヨ。
ある言語が好きと言う時は、言語設計部分を含めて言うピヨ。
そりゃいきなりどこが好きと言われても、彼女のどこが好きといきなり聞かれたようなもので明確に答えられないのは当たり前だと思うピヨ。
ちなみに、ボクが好きな言語はベスト3は・・・

1位・・・LISP、C++/C、アセンブラ
2位・・・C#、Ruby、SQL系
3位・・・D、VB.NET

# re: interfaceに物申す(3) 2009/01/09 17:14 インドリ

さっき書き忘れたけど、C++が仮想マシンを望んでいないと書いた理由は、ビャーネ・ストロヴストルップ氏がシステム言語であり続けると書いてあるからピヨ。
いきなりOS作りを拒否しているような言語よりも、C++の様に硬派で例え汚い点があっても維持する設計精神はもう技術者の鑑だと思うピヨ。
仮想マシンは好きだけども、皆が仮想マシン言語になったらOS作りの道は閉ざされ、技術者として不遇な毎日を送らねばならないピヨ。
一応仮想マシンでも無理やりOSを作れる方法はあるけども、それは最早コンパイラであり、その言語でOSを作ったとはいえないと思うピヨ。

# re: interfaceに物申す(3) 2009/01/09 17:29 επιστημη

「無差別に」機能を追加した言語で無いのは承知。

アナタは
「既存の概念を継ぎ足して」機能を追加するやり方
が気に入らんてことだったから、じゃぁC++は最低だな、と返しました。

...あ、そかそか、"機能を何でも追加したらいいわけはなく"が"無配慮に"を含意してるのか。

アナタがC++スキなのは「ネイティブコンパイラだから」
ではなく、「(メモリ1byteに至るまで)低いレイヤに潜り込めるから」ではないのかしら?

なんにせよアクセス修飾云々とは関係ないすけどね ^^;

# re: interfaceに物申す(3) 2009/01/09 21:31 インドリ

>ではなく、「(メモリ1byteに至るまで)低いレイヤに潜り込めるから」ではないのかしら?

その通りです♪


>なんにせよアクセス修飾云々とは関係ないすけどね ^^;

済みません。脇にそれちゃった。
C++の話しをしていて改めて思ったのだけど、最近の言語ってC++のアクセス修飾子とかを「拝借」している気がするピヨ。
C++以前にもアクセス修飾子はあったんだけど、D&Eを読むに考えずに追加したとはとても思えないピヨ。
プログラム言語が他の言語を参照するのはいいことなんだけど、でもその言語独自の設計思想が感じられないとボクは嫌なんだ。
それでラムダ式を一斉に追加した時もうかなり不満だったピヨ。
関数型言語から借りるんじゃなくて、C++がオブジェクト指向の考えを一新したのと同じように、既存の概念を変えて欲しいピヨ♪
なんというか、最近の言語の動きはビジネス的なんだよね・・・
○○機能を追加しました!
なんていったら宣伝になりやすいだろうけども、プロの道具としての言語を考えるのならば、プログラム言語は「アクセス修飾子の概念を一新しました!」とか言って欲しいですよねー♪

# re: interfaceに物申す(3) 2009/01/10 14:35 インドリふぁん

>済みません。脇にそれちゃった。

脇というか、最初から επιστημη氏のエントリと違う論点にいて、
さらに交わらない方向に向かっていろいろ書いていたようにしか
見えないワン。

# re: interfaceに物申す(3) 2009/01/11 9:25 aetos

だから既存の概念変えたら互換性なくなっちゃうじゃん…

タイトル
名前
URL
コメント