所謂オブジェクト指向言語はオブジェクト指向してないんじゃないかというなにか - にゃははー
※ネタです。マジレスしない様に ※重ねて言いますがネタです。 ※なんどもいい(ry まずは http://b0r0nji.blogspot.com/2011/12/blog-post.html を読んでください。 この説明でオブジェクト指向わかった！ってなったらそれどうなんだろうと思ってしまったわけです。で、オブジェクト指向プログラミング - Wikipedia読んでみると、 相互にメッセージ (message) を送りあうオブジェクト (object) の集まりとしてプログラムを構成する技法である。 ほう、メッセージとな。さて、先の説明にメッセージがあったか？となるわけです。 オブジェクトとはなにか 多くのOOPをサポートしていると謳っている言語はこのメッセージの送受信(Message Passing)をメンバ呼び出しという形に置き換えて、概念的にはメッセージを送り合って通信しているよう
小人閑居して: 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説
2011年12月6日火曜日 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 「ぐへへお姉ちゃんパンツ何色」はこれ以上ないほどオブジェクト指向であり、しかも理想的な実装をしていることに気づきました。これを用いてオブジェクト指向を説明してみようと思います。 ある人が「ぐへへお姉ちゃんパンツ何色」と質問するのは、お姉ちゃんオブジェクトの保持するpants_color変数を取得しようとする手続きと見ることが出来ます。つまり oneechan.pants_color を取得しようとしているわけです。 ではどうすればいいのでしょうか？ 考えてみましょう。直接パンツを見ればpants_colorを取得することができますね。 クラスを使わないとすればこんな書き方が考えられます。 struct oneechan{ int pants_color; }; 構造体でひな形を宣言します。
XE2 Developer's Guide and Reference
CLON stands for Common Lisp Object Network. CLON is a prototype-based object system for Common Lisp. It is different from CLOS in several important ways: CLON is prototype-based, not class-based. A prototype is a template object from which other objects are "cloned". Method invocation happens via message-passing, not generic functions; messages are conceptually different from synchronous function
Rifle-Oriented Programming with Clojure
Any comparison of hot JVM languages is likely to note that “Clojure is not object-oriented.” This is true, but it may lead you to the wrong conclusions. It’s a little like saying that a rifle is not arrow-oriented. In this article, you will see some of the ways that Clojure addresses the key concerns of OO: encapsulation, polymorphism, and inheritance. This is a whirlwind tour, and we won't have t
ハイブリッドOOPLの呪い - みねこあ
手続きプログラミングとオブジェクト指向プログラミングはなんだかどうも癒着してしまって、別のプログラミングパラダイムという気がしてこないのが、実は諸悪の根源なのではないかと思ってしまいます。 C++ なんかでは、OOPLになったといっても手続きを流し込む大箱が追加されただけで、メンバ関数の中に降りていけば、そこに見慣れた手続きプログラミングが広がっています。Smalltalk なんかですと、メソッドの中の小コードであってもこれはもう手続きではなくって、メッセージ式が連なっていく様はむしろ関数言語に似ています。 「純粋OOPL」「ハイブリッドOOPL」の違いは、「全てがオブジェクトであるか」とか「最初からOOPLとしてスクラッチビルドされたか、既存言語を増築したか」ではなく、実はこの差なのでは、と思います。sumimさんが啓蒙されているような「二つのOOP」があんまりフツーには知られていなかっ
Programming Language Soopy
はじめに。 Soopy とは、なるべくシンプルな文法を目指して 設計された関数型オブジェクト指向言語です。 Soopyの文法は、Lens,Eiffel,StandardML等から影響を受けていますが、 それらのどの言語とも似ていません。 入門(Tutorial) SoopyG Document Soopy Wiki Download Project Manager: randy
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
Perl5 のオブジェクト指向を理解する - モダンなPerl入門
Inside Perl5 OO 対象読者： 他の言語で OO したことあるっぽいひと/Perl4 でとまってるひと Class をつくる まずは点クラスをつくってみましょう package Point; sub new { my ($class, %args) = @_; # 第１引数はクラス名 bless({%args}, $class); # データを bless すると、オブジェクトになる } sub x { my $self = shift; # 第１引数は、インスタンス $self->{x} = shift if @_; # 引数があればセッター扱いになる $self->{x}; } sub y { my $self = shift; $self->{y} = shift if @_; $self->{y}; } このようにして作ったクラスは、下記のようにして呼び出すことができま
ファーストクラスオブジェクトとしてのメソッド - 世界線航跡蔵
Rubyと高階関数 : 関数そのものがファーストクラスではない やー、Rubyのメソッドはファーストクラスですよ。返り値にできて、変数に格納して演算できて、引数にできるという意味では。 確かに、RubyはPythonやJavaScriptやSchemeに比べると高階関数を陽に使うプログラミング *1 は不格好になる。Pythonなら簡単なのに、 bound_function = obj.hoge bound_function(arg1, arg2, arg3) Rubyは余計なメソッド呼び出しがくっついて不格好だ。 method = obj.method(:hoge) method.call(arg1, arg2, arg3) 私もこの点が気にくわなくてまつもとさんに「メソッドがファーストクラスだったらいいのに」と言ったことがある。でも、まつもとさんの考えではすでにファーストクラスというこ
Collection & Copy - JavaScriptにおけるプライベートメンバ
JavaScriptにおけるプライベートメンバ 翻訳 原文：Private Members in JavaScript Copyright 2001 Douglas Crockford. All Rights Reserved Wrrrldwide. JavaScriptはJavaScript: 世界で最も誤解されたプログラミング言語です。JavaScriptのオブジェクトが、プライベートなインスタンス変数およびインスタンスメソッドを持てないため情報を隠蔽する能力が欠けていると思われることがあります。しかし、これは誤解です。JavaScriptのオブジェクトは、プライベートメンバを持つことができます。その方法は以下です。 オブジェクト JavaScriptはオブジェクトを基礎としています。配列はオブジェクトです。関数もオブジェクトです。オブジェクトもオブジェクトです。それならば、オブジェク
Moose::Cookbook::Recipe1 - has, before, after, extends - - 日向夏特殊応援部隊
もの凄い乗り遅れた感ですが僕も Moooooooooooooooooose してみる。 とりあえず Cookbook をやってみる事にしてみました。 Moose::Cookbook::Recipe1 - The (always classic) Point example. - metacpan.org ソース まぁ適当にテストとか追加してある。 package Point; use Moose; has 'x' => ( isa => 'Int', is => 'ro' ); has 'y' => ( isa => 'Int', is => 'rw' ); sub clear { my $self = shift; $self->{x} = 0; $self->y(0); } package Point3D; use Moose; extends 'Point'; has 'z' =>
Moose::Cookbook::Recipe2 - class based constraint, modifier with arguments - - 日向夏特殊応援部隊
続いて Recipe2 をやっちゃうぞー。 http://search.cpan.org/dist/Moose/lib/Moose/Cookbook/Recipe2.pod ソース 預貯金に関する英単語が良く分からなかったので調べてコメント振った。 package BankAccount; use Moose; # 預金残高 has 'balance' => (isa => 'Int', is => 'rw', default => 0); # 預金する sub deposit { my ($self, $amount) = @_; $self->balance($self->balance + $amount); } # 引き落とし sub withdraw { my ($self, $amount) = @_; my $current_balance = $self->balance(
オブジェクトとクラス、とりあえずご質問に答えます - 檜山正幸のキマイラ飼育記 (はてなBlog)
「いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ」には、いろいろとフィードバックがありまして、僕もそれらに触発されたところもあるので、お応えしたい気もするのですが、なかなかにねー、、、エネルギーが足りないや。 とりあえず、明白に質問（疑問文）の形をしたものに答えます。 higeponさんの： 今日お話に出ていたCommonLisp(?)のすごいコードのお話ってどの辺に書かれていますでしょうか? aufhebenさんの： レイフィケーションとパワータイプって同じような概念ととらえてよいのかな? 檜山さんのエントリで、is-created-by とレイフィケーションは、他の関係と矢印の向きが逆な気がするんですけど、何か意図があるのでしょうか? id:higeponさんの質問は、当該エントリーとは別な文脈でのものですが、一連の流れとしては関連するので。 もし、「いまさらながらだ
perl - Class vs. Closure : 404 Blog Not Found
2008年07月13日03:30 カテゴリLightweight Languages perl - Class vs. Closure PERL HACKS(日本語版) [英語版] うーん、さすがにそれはいいすぎでしょうか。 クロージャの概念をクラスとの対比でわかりやすく説明する。 - サンプルコードによる Perl 入門 ここで気づいてほしいことは、クラスとクロージャは、実は同じものだということです。たしかにオブジェクトの定義から行くと、 404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス それで、オブジェクトとは何か、といえば、「自分が何が出来るのか[コード]を知っているデータ」ということになる。 であり、クロージャー(closure)は「自分が何を持っているか[データ]を知っているコード」なので、等価ではある。実際、 package Class; sub
なんで多重継承はそんなに嫌われるのか？ ちょっくら分析してみるか - 檜山正幸のキマイラ飼育記 (はてなBlog)
多重継承を嫌う人は多いですよね。「複雑だからダメだ」ってことらしい。でも、「複雑＝ダメ」はちょっと乱暴。必然性／必要性がある複雑さなら、それは受け入れざるをえないのですから。それに、どの程度の複雑さなのか、その複雑さはどこから来るのかを知らないと「ダメ」かどうかの判断はできないと思います。 という次第で、多重継承の複雑さを調べてみます。ダメかどうかの判断は僕はしません。圏論の道具を使うのだけど、事前の知識は一切不要です（最後の節を除いて）。最後にまとめて圏論的な解釈をしますが、ここは省略可能。 内容： クラスとその例 多重継承は集約と単純継承の組み合わせ 嫌われる理由 1：名前のバッティング 嫌われる理由 2：ダイアモンド継承 ダイアモンド継承の対処 とりあえずのまとめ 圏論からのアプローチと整理 クラスとその例 多重継承の話をするので、もちろんクラス概念は仮定します。でも、複雑さの話を複
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dto's clon at master - GitHub
MagicPoint presentation foils
http://swik.net/User:luchkovsky/JavaScript+Lazy+Inheritance+Pattern
Class-based programming - Wikipedia