デザパタ + Python／Ruby／Smalltalk part2

PythonやRubyと言った流行りのオブジェクト指向スクリプト言語や
Smalltalkといった、動的型付け言語に於いての
デザインパターンについて語るスレです。

・sage進行
・荒らしはスルー
・荒らしに反応するのも荒らし

前スレ
デザパタ + python
http://pc11.2ch.net/test/read.cgi/tech/1172431242/

ああ、隔離スレッドもここまで来たか

まだ埋まって無いじゃん

本スレより勢いあるしな

関連スレ

「【GoF】デザインパターン 6
http://pc11.2ch.net/test/read.cgi/tech/1141846078/

痛い名前でたったなぁ
なんでrubyとsmalltalkを含めるのか疑問、
ただでさえpy派とrb派じゃうまく議論できないのに、・・・

まともな議論スレになるとは誰も思ってないし
どうでもいいんじゃねぇの

厨房同士を暴れさせて消耗させるスレッドか。
じゃあ見る価値ないね。
削除っと。

前のスレ埋めないのか？

ﾜﾛﾀ

オリジナルのプログラムをお持ちの方いらっしゃいませんか？
この度クレジット決済でスムーズにダウンロード売買が
できるサイトを立ち上げました。
つhttp//web-cart.jp/
※会員登録&商品のうｐ全て無料です！
クオリティの高い商品のうｐをお待ちしてますｗ

次スレまで立てるとは、信じられん…

スーパー構ってちゃんの版画の仕業だろ。
いじってもらわないと、リアルでの孤独と寂しさに押し潰されて、吊りかねない奴だからな。

このスレ、伸びないと思う…。
いま、デザパタ分かってるの、Java か C++ の人がほとんどなわけで、
その人たちを排除しちゃったわけだから。

もっとも、このスレが深く沈んでも、困る人もいないと思うけど。

おい、冷静になって周りを見てみろ。

いまさらデザパタ、デザパタ、うるさくわめいてるのは
あんさんだけでっせｗ
みんなとっくに理解して先進んでまんがなｗ

誤）理解して先進んでまんがなｗ
正）理解しないで先進んでまんがなｗ

ただし、Java と C++ 使いは、とっくに理解して
先に進んでいるけど。

昔話が好ずきなじじいの戯言としてスルー




もし豆腐にセンスがあったら
「LLプログラミング作法」とか
「LLプログラミングtips」とか
コモン・イディオムとか
もっとお洒落な名前付けりゃ
単行本化して100万部突破、
映画化だって夢じゃなくなくなくなくなくなくないのになｗ

残念でした、涅槃で頑張れ

ま、LL側に謙虚な気持ちがなけりゃ、
Java使いにしろ、C++使いにしろ、教えてあげようという
気にはならないでしょう。

スレからして、JavaやC++は排除のようなので、
これにて失礼。

はぇぇっ
もう敗北宣言かよっ


狂信者弱ぇぇ〜
そして明日からまたPythonも使えるSIer担当者の下で
這いつくばって奴隷作業すんだろどうせｗ

掲示板で負け、現実で負け、
いいとここれっぽっちもねぇなぁ〜

観察事項１： 狂信者ﾀﾝはSmallTalk(ﾏﾏ) が出来ない

>>20
おまえもな

はあ？

人の説明も文字通りに受け取れん
猜疑心の強いバカか。疲れる奴

Warning:ローカルコンテキストが共有されていません。

前スレ読んでたRuby使いだけど
abstractメソッドする方法ないかなーって気になって
ちょっと考えてみた

require 'abstract'

class MyAbstractClass
　extend AbstractClass
　abstract :hoge
　abstract :fuga
end
class MyClass < MyAbstractClas
　def hoge
　end
end

obj = MyClass.new

# abstract.rb

class Module
　def abstract(*names)
　　if class_variables.size > 0 then
　　　class_variable_get(:@@ABSTRACT_METHODS).push *names
　　else
　　　class_variable_set :@@ABSTRACT_METHODS, names
　　end
　end
end

module AbstractClass
　def new(*args)
　　obj = super(*args)
　　class_variable_get(:@@ABSTRACT_METHODS).each do |m|
　　　unless obj.methods.include?(m.to_s) then
　　　　raise format("Abstract method `%s' not defined", m.to_s)
　　　end
　　end
　　return obj
　end
end

GroovyとかECMAScriptとかpnutsとかのデザインパターンもここでOK?
あとGroovyとJavaにまたがるパターンとかは？

観察事項１： 狂信者ﾀﾝはSmallTalk(ﾏﾏ) が出来ない

>>26
Java が絡むものは対象外ということで。

観察事項２： 狂信者ﾀﾝはしつこくJavaにこだわるｗ

>>26
動的言語なら良いんじゃね？
とはいえ元々隔離スレなんだから細かい事気にするなｗ

>>30
Javaがらみは荒れるからダメ。スレタイは、Java関係の拒否を表明したもの。

観察事項3:このスレの住人は約一名

>>32
あんた、何者？
Java関係者なら、出ていってくれないか。

観察事項４：唯一の住人＝狂信者は今やＣＯＢＯＬｅｒ

Java関係者なら、とっとと出ていけよ。
豆腐だとか、版画だとかの罵りあいにはウンザリなんだ！

>>20, 29, 32, 34 は、ただの粘着な偏執狂だろ。
いまどき、Java を使ったことがない人の方が珍しいくらいなんだから、
Java 関係者に出てってくれはあんまりだ。


>>24
使わなかった場合、
実行時に、メソッドを呼び出そうとして例外スローされて、
使った場合、
実行時に new で例外がスローされるの違いか。

クラス変数を使うのは行儀が悪い気がするな。

COBOLer乙

>>36
>Java 関係者に出てってくれはあんまりだ。

とりあえず了解。
ただし、また豆腐だとか版画だとかの罵りあいが始まったら、
Java関係者の拒否を表明します。

観察事項５：狂信者の自作自演は文体が全部一緒なので判りやすい

>>37
わりと触ったことのある言語は多いが COBOL は触ったことがない罠。

観察事項６：ＣＯＢＯＬ現場に常駐しながらＣＯＢＯＬ触ってないコイツって何？ｗ

狂ったJava使いは、全員出ていけ！

アドバイス： >>42キミのことだ

いいか、豆腐も版画も出ていけ！！！

>36
俺もクラス変数は行儀が悪いかなとは思ったが
それ以外にしっくり来る方法が思いつかなくて。

まあ、組み込みライブラリですら前者の方法を取ってるRubyで
わざわざ継承先の挙動を制限する必要は無いかもね。

観察事項：ＯＫＯＫ。住人は狂信者さん一人だけしか居ませんよ、もともと

観察事項７：書き込みが約30秒おき

豆腐や版画はもちろん、
Javaがらみのことは、絶対に書き込むなよ。
いいな。

似非コンサルが大規模ＯＯ開発に失敗してデスマった

観察事項８：どうやら発狂して、書くべきではない事を自爆した模様

うせろ！　Java野郎！！！

　　　その後、狂信者の姿を見た者は誰も居ない。。。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　−−　糸冬　−−
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　提供：２ちゃんねる
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　出演：狂信者

こ・この流れは……
もしかして、Javaがらみがどうのって書いてる人と、
観察事項って書いてる人って同一人物・？ｗ

視聴者の感想：糞だった

もしかして、豆腐も版画も同一人物？

リアルタイムで粘着さんを見るのはなんだか新鮮だった。
ちょっと出かけてくるね。

発狂乙似非コンサルたん

真面目にやってるのは Rubyの人たちだけだね…

ここ、なんで荒れてるの？

禁止されている特定の話題や単語には誰も触れていないのに。

デ☆ザ☆パ☆

Java関係の話題は、くれぐれも止めてください。
（Java関係者は即刻退去してください）
さらに、Cobolの話題も禁止にします。

これは、全スレがJava関係者と思われる豆腐と版画という
人物の罵りあいに終始したためです。

スレタイをよく見てください。
Java関係者は、豆腐であれ版画であれ、それ以外の人物であれ、
出入り禁止です。その点、くれぐれもよろしく。

そもそもMatzはJavaは一切やらない人？

Javaに一度でも手を付けた事がある人を全部排除したら、
残りは初心者だけになるんじゃないかな？

Smalltalkerも、ほとんどJava遣いだよな。
すると、Smalltalkも排除？

Python遣いだってほとんどの人は
別に母国語みたいなプログラミング言語を持っている。

Javaの人はいりません。ここから退去願います。
いなくても、別に困りません。

すると、SmalltalkerもPython遣いもMatz関係も全部追い出して、
スレを占有しようという魂胆ですね？

スレ占有は削除対象じゃなかったっけ？

Java を使わないPython とRuby とSmalltalk の人が残るでしょう？
それだけで十分です。
あと、Javaを一度は使ったけれど、いまは捨てた人もおｋでしょうね。
現在、Javaと関わっている人、Javaを評価してる人はお断りです。

なんかちがくね？

誰でも気軽に使えるのが
ライトウェイト・ランゲージのメリットなのに、
排除排除で小さくまとまろうとするのは
まるでカルト集団の分裂と粛清を見ているかのようだ

思想信条の自由を受け入れられない集団は
やがて自壊する

GuidoはJava評価してるよ。3.0のIOかなんかはJavaの仕様を入れるとかだった。

良い物は良いと認め、良くないと思う物に対しては率直な意見を述べ、
お互いの考えの違いを尊重しながら歩み寄る。
でも決して、非合理で説明のできない理由で他人や考え方を攻撃しない

それこそが大切な姿勢なのだと思うが、どうかな。

どんな理屈をこねても、
前スレや周辺スレの、豆腐 対 版画 の罵り合戦見れば、
なんの説得力もない。
Javaなど興味もないし、どうでもいい。
のんびりと、LL言語のコードの紹介をし合っていけばいいんだよ。
Java関係者は、とにかく消えて。ウザイ。

私怨で言語ごと嫌いになるのって愚の骨頂

>>73
彼の場合、自分で設計したコードでデスマって以来、
極度のJava嫌いになっている様子だ。

PythonにJavaの特性を求めたりする不可思議行動の原因は、
全てそれ。

まるでytakagiそっくりの駄々っ子だな

>>74
Javaの話題は禁止だぞ。
もし、Javaの関係者なら出ていってくれ。

>>76自身が一番問題児なんじゃねぇの？

ytakagi本人と見たｗ

>>78
いいかげんにしろ。
君は、あの馬鹿げた罵り合戦を忘れたのか？
Javaなんかに関わりあうからああなるんだ。

LL言語だけでノンビリやろう。
インターネットで捜せば、以外とあちこちにコードはある。

>>79
なかなかしらじらしい奴だな

デザパタスレで毎回毎回念仏のような説明を繰り返してるある人物が、
何かが原因で発狂して、相手構わず暴れていた
というのがあの事件の真相。

でもそいつの身元は、親切な情報提供によってすでに割れている。
そいつが今更このスレで暴れられる訳がないだろ。

スレタイを見ろ。
Javaが入ってないのは分るよな？

こっちも一歩譲ろう。
別なところでどれだけJavaを使っていてもかまわない。
でも、ここでJavaを話題にするな。

これでいいだろ。
ここではLL言語や動的型付け言語のみについて話す。
Javaについて話したいなら、他所でする。（デザパタ本スレもあるんだし）
そういうことで。

誰もJavaの話題になど触れていない。
それにも関わらず、君が独りでヒステリックになっている。

これが現状

> デザパタスレで毎回毎回念仏のような説明を繰り返してるある人物が、

あいつは確かにウザい。
一般的ではない(間違った)独自解釈振り回して
延々と自作自演の議論を展開するし。

Javaの話は止めろ。

どうやらこのスレの主は
幻覚を見ているらしい。

Javaの話は別なところでやれ。
デザパタ本スレでやれば、誰も文句は言わない。

さっきから見てると
キミは、まるで頭のおかしな人のような振る舞いばかりしている。


その原因は何だ？

Javaの人ですか？
それなら、豆腐や版画の仲間ですね。
消えてください。

ytakagiってバカなんだな。

キミがおかしくなった原因は何だ？説明してみたまえ。

誰かがキミの抱えている問題を解決してくれるかもしれん。

さあ、心を開いて語ってみそ

Javaの人ですか？
それなら、豆腐や版画の仲間ですね。
消えてください。

何が原因でキミは壊れたのか
理由を教えてくれ

お前ら、下らないことやってないで、
コードの一つも書けや。あほくさ。

Javaの人ですか？
それなら、豆腐や版画の仲間ですね。
消えてください。

Javaの人ですか？
それなら、豆腐や版画の仲間ですね。
消えてください

Javaの人ですか？
それなら、豆腐や版画の仲間ですね。
消えてください

>>24,25 を Squeak Smalltalk で意訳してみました。#subclassResponsibilityなメソッドが未再定義だと警告。

Trait named: #TShouldBeDefinedAlert

TShouldBeDefinedAlert classTrait >> new
　 | shouldBeDefined |
　 shouldBeDefined := (self allSelectors
　 detect: [:sel | (self lookupSelector: sel) messages includes: #subclassResponsibility]
　 ifNone: [^super new]).
　 self error: shouldBeDefined printString, ' should be defined'


Object subclass: #AbstractMyClass
　 uses: TShouldBeDefinedAlert

AbstractMyClass >> hoge
　 self subclassResponsibility

AbstractMyClass >> fuga
　 self subclassResponsibility


AbstractMyClass subclass: #MyClass

MyClass >> hoge
　 ^#something

- - - - - - - - - - - - - - - - -

MyClass new "=> Error: #fuga should be defined"

Smalltalk使いが実際に来たら停滞したなｗ

無知で申し訳ないんだけどSmalltalkって
どんな分野で使われてる言語なの？
デザパタ本ではじめてその存在を知ったんだけど

特に分野は決まっていないよ。最近一番採用されてる例としては OLPC かな。
何でそんな事知りたいの?

>>99
よく知らないんだけど、事例集っぽいのをピックアップしてみた。

Squeak Smalltalk　（Apple Smalltalkの生き残り）
http://squeakland.jp/school/schoolhome.html
http://www.seaside.st/
　http://dabbledb.com/
http://www.croquetconsortium.org/index.php/Current_Projects
　http://japan.internet.com/webtech/20070314/12.html

Cincom Smalltalk　（XEROX Smalltalkの生き残り）
http://smalltalk.cincom.jp/scripts/smalltalk.dll/customer/applicationj.ssp
http://smalltalk.cincom.jp/scripts/smalltalk.dll/customer/applicationw.ssp
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?C3
http://www.whysmalltalk.com/production/

IBM Smalltalk　（すでに死亡）
http://www-306.ibm.com/software/awdtools/smalltalk/about/

smalltalkつったらここじゃね？
http://www.sra.co.jp/people/aoki/

>>99
大体どの分野でも使われてると思うけど、医療事務系とかが多いんじゃね？

>>97 の
(self lookupSelector: sel) messages includes: #subclassResponsibility

は、

(self lookupSelector: sel) isSubclassResponsibility

で、おｋ。

>>100-103 ありがとう

>>100
オレは組み込み系でCからC++に移行したんだが
どうもOOPとかデザパタについてしっくりこないというか、
理解が浅い気がするので、アプローチを変えて動的型づけの言語を
試しにやってみようかと考えてたところ
Wikiみたらオブジェクト指向の手本だとか、デザパタの宝庫という
文字をみてちょっと興味を持った。歴史のある言語みたいだね

> オレは組み込み系でCからC++に移行したんだが

最近組み込み系の書籍漁りしてる厨房か

>>103
もしかして大学病院とか?

>>105
IDE の中に OS が入っている様な感覚は、最初は異様に感じるかもしれないね。

なんじゃその感覚

>>108
Smalltalkのことじゃね？
あの言語でインタプリタ単体の環境は俺は聞いたことがない
ほとんどはSmalltalk環境自体が一個のシステムって感じ

じゃあsmalltalkのx64ネイティブコンパイラとか卒業研究のネタに使えるって事ですか？

Smalltalkを指して「IDEの中にOSが入っている」と言うのは
また例のバカの妄想だろう

卒研なら大目に見てもらえるんじゃね。

鈴木高弘の発言はいつも知ったか。
恥ずかしくて見てらんない

逆に考えるんだ。

IDEの中にOSが入っているんじゃなくて、
風変わりなOSの試作品を無理矢理IDEっぽく見せて使わせてるんだ。

http://d.hatena.ne.jp/umeaji/20060721/p1

また知ったかか

いちいち他人をけなさないと気が済まない奴が居るみたいだなあ...
スルー力低過ぎ。

だが表舞台には立てない言語
それがスモールトーク
そしてそれを愛するスモールとーカーも表舞台には立てない

Smalltalk関連の研究と言えば、
1980年代前半ならSmalltalkVMと専用CPUの実装が博士論文になってたな。
1980年代後半だと並列化やマルチパラダイム化
1990年代初頭だとプロトタイプベース・オブジェクト指向言語の実装
1990年代後半だとリファクタリング絡みやアスペクト指向
1990年代後半に入ると、JavaVMが普及してきて、
SmalltalkVMを使う必然性が薄らいできているような気がする。
まあSmalltalk上の資産や蓄積、ノウハウによっぽどの思い入れがあれば、
今でも研究プラットフォームたりえるんだろうけど。

なんだ無茶苦茶表舞台に立ってるやん
国内の開発者にヘタレが多いだけじゃないの？

どっかのバカが大規模開発なんか始めなければ
もっと有意義な成果が出てただろうにね。
大規模開発なんてどうせバカしか集められないんだから
先端技術を使って破綻して迷惑をかけたりせずに
隅っこの方でCOBOLer集めてチマチマやっとけってんだ。

誤解を恐れず言えば、Java も最初は Smalltalk だったんだけどね。
IBM(VisualAge) のも Sun(Strongtalk) のも

VisualAgeそのものとJavaは関係ねぇだろ
VA自体が元々Smalltalkかなんかで記述されてた
という話は聞いた事あるけど。

StrongtalkVMに関しては
その技術がJavaVMにも転用されただけじゃないか？

学校の教師

気持ち悪い物体がこびりついているな

やめて

　　　 　　　　　,-､　　　　　　　　　　　　,.-､
　　　　　　　 ./:::::＼　　　　　　　　　 ／::::::ヽ
　　　　　　　/::::::::::::;ゝ--──-- ､._/::::::::::::::|
　　　　　　 /,.-‐''"´ 　　　　　　　　 ＼:::::::::::|
　　　　　／　 　　　　　　　　　　　　　　ヽ､::::|
　　　　/　　　　　　　　　　　　　　　　　　　ヽ|
　　 　 l.　　 　　　　　　　　 　 　 　 　 　 　　 l
　　　 .|　　　 ●　　　　　　　　　　　　 　 　 　|
　 　 　l　　, , ,　　　　　　　　　　　●　　　　　l
　　　　` ､　　　　　　(__人__丿　　　　､､､ 　 /　>>1 糞スレ
　　　　　　`ｰ ､__　　　　　　　 　　 　　　 ／
　　　　　　　　　/`'''ｰ‐‐──‐‐‐┬'''""´
　　　　　　　　./　　　　　　　　___　l　__
　　　　　　 　 l　　 ./　　　　／　 |／　|
　　　　　　 　 `ｰ-<　　　　/　　./　　./
　　　　　　　　　　　`ｰ‐--{___／ゝ､,ノ

>>25
なんでいちいちclass_variable_get使ってんの?

(@@ABSTRACT_METHODS ||= []).concat(names)
@@ABSTRACT_METHODS.each
でいいじゃん。

ケンカするほど仲がいい

>>127
仮想クラスを２つ作りたい時のため。
直に扱うと個々のクラスじゃなくて親のクラスのクラス変数になってしまうみたいで
全ての仮想クラスで@@ABSTRACT_METHODSが共有されてしまう。
…ってもしかして 1.9.x ではならないのか？

久しぶりに覗いたついでに書き直しとく…
:@@ABSTRACT_METHODS 書き過ぎだよ、過去の俺

class AbstractMethodNotImplementException < Exception; end
module AbstractClass
    def abstract(*symbols)
        abstract_methods.push *symbols
    end
    def abstract_methods
        sym = :@@ABSTRACT_METHODS
        class_variable_set(sym,[]) unless class_variables.include?(sym.to_s)
        return class_variable_get(sym)
    end
    def new(*args)
        obj = super(*args)
        abstract_methods.each do |sym|
            raise(AbstractMethodNotImplementException, "abstract method `#{sym}' is not defined") unless obj.methods.include?(sym.to_s)
        end
        return obj
    end
end

# sample
class MyAbstractA
    extend AbstractClass
    abstract :method_a
end
# class MyImplementedA < MyAbstractA
#     def method_a; end
# end
MyImplementedA.new

ちなみに、get だけで使うとそれはそれで
uninitialized class variable になるよ。

VisualWorks7 でファイルアウトをマウス操作でなく実行命令として
記述するにはどうすればいいですか。

>>132
こういうのじゃ駄目なの？

| fileManager |
fileManager := SourceCodeStream write: NameOfClass printString, '.st' encoding: #Source.
fileManager timeStamp.
NameOfClass fileOutSourceOn: fileManager.
fileManager close

>>133
ありがとう。できました。あなたは神様です。

'aClass' という文字列から aClass というClassオブジェクトを取得するには
どうすればいいですか。

Compiler new evaluate: 'aClass' in: thisContext receiver: nil notifying: nil ifFail: []

cls = globals().get("aClass")

ってSmalltalkか。

>>135
そっか、aClassという名前のクラスを得たいのか。（ってそう書いてあるじゃんｗ）
そうならば137のRubyと同じ方針で、

Smalltalk at: 'aClass'

でおｋ。（136でもできるけどね）
老婆心ながら、クラス名は小文字ではじめないほうがいいと思います。

137はpythonだべ

がーん。ｗ　Ruby だと、

Object.const_get("AClass")

か。orz

ありがとうございました。みなさん

>>136 みたいなのを見ると Smalltalk は自然言語に近くて良いなあと思うけど、
英語が嫌いな人にはキツそうだね。

開発でC++使ってるとC++の勉強で手一杯になっちゃってsmalltalkまで手が回らん

そこをなんとかまわしてください。

ドリルは漢のロマン

>>144
smalltalkを先に勉強すればC++は勉強しなくても使える

C++ はテンプレートライブラリ用言語だから Smalltalk を
知っていても何の役にも立たないと思うけど

boost使うなら役に立たんこともない。けれど原則SmalltalkとC++はＯＯの考え方じたい別もの。

>>148
> C++ はテンプレートライブラリ用言語だから

ゲラ

smalltalkを先に勉強すればC++は怖くて使えないチキンになる。

と、smalltalkの読み書きもままならない151が言っております。

と、SmalltalkもC++も全然読めない＆書けない151が言っております。

と、エロ本読みながらマスかいている俺が言ってみるテスト

age

>154
片手塞がっててもう片手もページめくってるのに、よく書けるな。

>>156
横にいる彼女に代筆してもらってる

漏れは彼女に筆をおろした

彼女がエロ本読んでる横でマスかきながら2chやってるか
彼女がマスかいてる横でエロ本読みながら2chやってるな

pythonの言語仕様には問題があると思う。
>>> a=1
>>> a.__str__
<method-wrapper '__str__' of int object at 0x00AB5670>

>>> a='abc'
>>> a.__str__
<method-wrapper '__str__' of str object at 0x00DB4FE0>
>>>
最初はint型として解釈されるけれど文字列を代入した時点でstr型になっている。
オブジェクト指向なのにBASICが抱えていた古典的な教訓がまるで生かされていないよ。

プロの現場が必要とする大規模開発でpythonが採用されるはずが無いのでは？
なのにデザインパターンを語っても意味はあるのだろうか？
デザインパターンの前に言語仕様そのものを見直すべきではないだろうか？

python好きの方には申し訳ないけど．．．

動的型付けを全否定w

追記します。
「a='abc'」をプログラマが実行してしまった時点で最初の「a=1」には二度とアクセスできない。
そう。a=1で生成されたインスタンスはゴミとしてメモリに残る訳だ。

gcの機能はあるらしいけれど．．．バグだらけ。
さっき試したらIDEが吹き飛んだよん。

動的型付けはいいと思うよん。利用者側にとって好都合だからね。

上記はあくまでも利用してみた感想さ。
悪く思わないで下さいね。

まだまだpythonは言語拡張の必要性はあると思う。

もう一言
a=1のインスタンスのメモリ番地は0x00AB5670
a='abc'のインスタンスのメモリ番地は0x00DB4FE0
表記はどちらもaだけれど別インスタンスです。
動的型付けではないですね。

なんという釣り針。

>>165
あなたになにがわかりますかね。
Pythonという言語の馬鹿さ加減を指摘しただけなんですけどね。
大学出てない人ですか。

大学出てないかどうかと、この件がどうかかわるのか皆目わからんな

>>160, 161-164です。
166の発言は私ではありません。

asm,CはOSやハードウェア(下位レイヤ)の性能を100[%]引き出せるように考えられたボトムアップアプローチだった訳です。
ハードウェアやOSリソースを100[%]効率よく使えるようにデザインされていた。

しかし、純粋オブジェクト指向言語はトップダウンアプローチ
つまり、理想ありきで下位レイヤの機能やリソース(OSやハードリソース)は使わない方針なんですよ。
そこんところを改善するべきだよね。標準modulesにDBへのアクセス機能がないのもチトどうかと思う。

折角お金をだして購入した機能やリソースは100[%]使い切りたい。
これって普通の人間の普通の希望じゃないだろうか？

まあ、こういった問題はpython使いが増えれば改善されるかな。

>>160, 161-164です。
166の発言は私ではありません。

asm,CはOSやハードウェア(下位レイヤ)の性能を100[%]引き出せるように考えられたボトムアップアプローチだった訳です。
ハードウェアやOSリソースを100[%]効率よく使えるようにデザインされていた。

しかし、純粋オブジェクト指向言語はトップダウンアプローチ
つまり、理想ありきで下位レイヤの機能やリソース(OSやハードリソース)は使わない方針なんですよ。
そこんところを改善するべきだよね。標準modulesにDBへのアクセス機能がないのもチトどうかと思う。

折角お金をだして購入した機能やリソースは100[%]使い切りたい。
これって普通の人間の普通の希望じゃないだろうか？

まあ、こういった問題はpython使いが増えれば改善されるかな。

>>169
> ハードウェアやOSリソースを100[%]効率よく使えるようにデザインされていた。

C言語でスタックやフラグレジスタにアクセスできないことに四苦八苦したことが
ある俺から言わせてもらうとこの時点でお前の俺様的空論なんだが。

>>160, 161-164です。
166の発言は私ではありません。

asm,CはOSやハードウェア(下位レイヤ)の性能を100[%]引き出せるように考えられたボトムアップアプローチだった訳です。
ハードウェアやOSリソースを100[%]効率よく使えるようにデザインされていた。

しかし、純粋オブジェクト指向言語はトップダウンアプローチ
つまり、理想ありきで下位レイヤの機能やリソース(OSやハードリソース)は使わない方針なんですよ。
そこんところを改善するべきだよね。標準modulesにDBへのアクセス機能がないのもチトどうかと思う。

折角お金をだして購入した機能やリソースは100[%]使い切りたい。
これって普通の人間の普通の希望じゃないだろうか？

まあ、こういった問題はpython使いが増えれば改善されるかな。

空論ですか．．．ならば
>>160, 161-164
に具体的にコメントしてくれよな。
もっともいざこざは面倒なので空論でも結構だけどさ。

ところで純粋に疑問なのですが、
>C言語でスタックやフラグレジスタにアクセスできないこと
pythonではスタックやフラグレジスタ(cpuリソース)に明示的にアクセスできるの？

ちょっと勉強させてくださいな。

天然物？まさか、な…

pythonはmac, solaris(cpuはsparcアーキテクチャ)でもliunx,windows(cpuはインテルアーキテクチャ)でも動くみたいだよ。
cpuアーキテクチャがまるで違うのにpythonではcpuリソースに一元的なアクセスが可能なの！？

無理だと思うけどなぁ〜。

pythonのチュートリアルを見るとスタックやキューの話がサンプルで出てくるけれど、
これらはCPUの動作を真似たサンプルコードというだけで
本物のCPUリソースへアクセスしている訳ではないと思います．．．

まあ、いいや。

立場は違えどpythonというキーワードに触れるだけでもハイレベルな人たちだと思いますので
私から皆様へ敬意を表した上で退散させて下さいな。

天然かなこりゃ

たくさん釣り針を残して逃げたw

>>161
いや、静的型付けOOをも否定しているw
つーか、ポリモーフィズムの否定だwww

どうやら答えられないようですね。

はっきり答えを導ける人は2chにいなかったようですね。さみしいな。

んなこと言われても、何をどう答えていいのかわからんしな・・・
色々とトンチンカンというか、動的言語云々の前にOOP自体よくわかってないみたいだし。

>168 です。
python(パイソン)をいろいろと否定したような掲示をしたけれど
本当にダメな言語だと思っているならわざわざ言語仕様を調べたり勉強したりなんかしないぞ。

以下のURLを見て欲しい。Google Data APIにpython版が発表されている。
http://code.google.com/p/gdata-python-client/

Googleの技術者はGoogle Dataを普及させる為にpythonによるclientが強力な開発ツールになると判断しているんだ。

Google Data APIを利用できる言語としてJava, PHP, .NETなんかが採用されているみたいだよ。
ASMやCでは無理って事さ。
道具はその場その場で使い分けろって事なんだろうね。

先のURLからAPIをダウンロードするとデザインパターン with pythonの未来が見えるかもよ。

そこの君、俺は色々変な掲示をしてしまったけれど気を悪くしないでくれよな。
じゃあな！！

いいか、英語が読めないといい大人になれないぞ！
あとPythonを使ってる君！C++に切り換えるとか考えよう！

じゃあな！！

　　　　　　　　　　　　　　 .| 　 |　　|　|　　 |　 　 |　　| ｜ 　 |　　 | 　 |｜　|　|
　　　　　　　　　　　　　　 .| 　 |　　|　ﾚ　　|　 　 |　　| ｜ 　 |　　J 　 |｜　|　|
　　 　∩＿＿＿∩　　　　| 　 |　　| 　 　 J　 　 |　　| ｜　　し　　 　 |｜　|　|
　　　 | ノ＼　　 ,＿ ヽ　　.| 　 ﾚ　｜　　　　　　｜　 ﾚ｜　　　　　　　|｜ Ｊ　|
　　　/　　●゛　　● | 　 .J 　　 　 し 　 　 　 　 | 　 　 |　　　　　　　｜|　　 J
　　 |　∪　　( _●_)　ミ　　　　　　　　　　　　　.｜　 　 し 　 　 　 　 J｜
　　彡､　　　|∪|　　 |　　　　　　　　　　　　　　.Ｊ　　　 　 　 　 　 　 　 ﾚ
　/　　　　 ∩ノ ⊃　 ヽ
　(　 ＼　／ ＿ノ　|　 |
　 ＼　 "　 ／　　｜　|
　　　＼ ／￣￣￣ ／
　　　　　￣￣￣￣

なんなんだこのスレは(笑)

まぁ変な「掲示」だったということで

BASICの型付けとPythonの型付けは全然別物なんだがなあ…
VBのVariantに近い型付けをする言語って何だろ。あんまり知らないな。

>>186
Pythonの方でしょうか。
正直僕の小論に答えられないということを認めたほうがいいと思いますよ。
他の言語を引き合いに出して型付けが別物とか誰でも言えます。

>>187
http://ja.wikipedia.org/wiki/%E3%83%9D%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%95%E3%82%A3%E3%82%BA%E3%83%A0

>>188
そんな寄付によって成り立っています、みたいなバナーを出す詐欺サイトを出されても困りますよ

権威あるwikipediaを詐欺サイト呼ばわりとは．．．

善意の寄付で成立する詐欺サイト．．．

聞いたことねぇ。(^_^)

善意の寄付で成立する詐欺サイト．．． って
自分の親にオレオレ詐欺するようなもん？

wikipediaを権威あるとか言っちゃう男の人って・・・

>>191
死ぬ死ぬ詐欺

wikipediaより権威あるサイト

つまり、こうだ。

有志の方がんばって百科事典つくりましょう＼(＾o＾)／
↓
便利な百科事典できました
↓
つぶしたくなかったら、寄付しろ

だから何。
何かを作る過程にはボランティアの人は寄ってきても、
長く辛いだけでしかないメンテに人はよってこないし、
成果物の恩恵に与る側からの寄付でメンテコスト捻出とか、
ごく普通のライフサイクルですが。

Wikipediaの情報をソースに取る馬鹿が大量にいるスレはここですか?

Wikipedia に書かれてる内容では判断できないので
レッテル貼りに終始するお前のような馬鹿ホイホイのためのスレですお

やはり答えを出せる人間はここにはいませんか、
やれやれ。

>>199
スレ違い

スレ違いつーか、カン違いつーか、アサッテっつーか、ナナメ上っつーか。

どもっ！
>>168を掲示したオリジナルです。(　>>199とは別人です。　）

＞＞まあ、こういった問題はpython使いが増えれば改善されるかな。

で自己解決ですな。俺は168で答えは求めてないぜ。

要するにパイソンユーザが増えて下位レイヤのデバイスを表現するクラスがバンバン作られればパイソンの名も上がるだろうと思うよん。
その時にデザインパターンが活用されれば間違いないと思うよ。

よくわからんがboost.pythonとかctypesのことを言っているのか？

そうそう、最後に言い忘れてたっ！
パイソンを使い続けるとデザインパターンを学ぶ時に大変くろうするかな。

早めにJavaを初めて、パイソン捨てる事をおすすめしますよん。

ではでわっ！！

デザインパターンは動的型のほうが親和性が高いっつーか、
デザパタ自体がもともとSmalltalkから派生した考えだということ
知らないんだろうなあ・・・

> パイソンを使い続けるとデザインパターンを学ぶ時に大変くろうするかな

オートマ車に乗り続けるとクラッチ操作を忘れてしまうってことですね？

・・・本末転倒だろ・・・

むしろデザパタを、パターンとしてでなくメカニズムとして実装できたりもするけどな。
というか静的型言語厨でした、というオチですか。

>>207
C++使って糞コード書いている奴でもこんな変な事は書かない。
「処理系」というものが頭にない奴なんじゃないのかな。
PythonはPythonたるもので出来ているとかそう思い込んでいる。(pypyというプロジェクトはあるが。)

やはり、2chは馬鹿の塊のようすっ
いっとくけど俺は>>204書いてないぞ

しかし同意できるのはPythonの人たちはねちっこいから
何も言えなくなるってことだね。自分たちの知識不足についてまったく追えていない。

だってぼくあほやしー

>205
デザパタのうちのいくつかは「静的型で動的型っぽいことをする」ためのパターンでもあるしな。

初心者（python以外のプログラミング言語とか知らない、
書くのは何の役にも立たないような計算とかリストを返すプログラムのみ）
のおれが言うのも何だけど、pythonでＯＯとかパターンとかやる必要ないんじゃないの？
関数で書けばいいじゃん
関数でリストを返してlambdaするインタプリタを書けばいいんだよ

多分、ここの人達が想像できないくらいの初心者なので
とんちんかんなことを書いていると思うけど、
プログラムは世界を救うためにあるんだろう
人を幸せにするためにプログラマがいるんだろう
無意味な争いがしたいだけなら、ゲームでもやってろと思った
オブジェクト指向とかライブラリとかインターフェイスとかパターンに
囚われることが本当に世界救済につながるのかどうか考えてください。
おれはAppleIIみたいなのをpythonで作れるとか思っているほど知識に乏しいので
プログラムなどは使うだけで満足なんですよ、便利だし
それを作るのはあなた達です、頑張ってください。

パターンなんて知らなくてよい

2chで回答を得るためによく使われるもの
狩パターン
釣パターン
煽りパターン
初心者パターン
クレクレパターン

デザインパターンは設計のノウハウを再利用するためのものであるのだから、
設計するまでもなく簡単に実装できればパターンですらなくなってしまう。
クラスやモジュールの形で供給されたり、言語に組み込まれて簡潔に書けるものはパターンとは呼べまい。

Singletonはメタクラスで表現できるし、
Iteratorはジェネレータ構文やブロック付きメソッドですぐ書ける。
Strategyは関数がファーストクラスの言語ではそもそも関数渡せばいいし、
boostにはflyweightクラスがあるし、
pythonにはデコレータ構文があるし、
いわゆるGoFのデザインパターンは時代と共に減っているんじゃないだろうか？

>>212
関数で状態を表現するのはかなり気持ち悪い
状態なんかなくてもいいやい！とか思ってるんならHaskellとかお勧め
……Compositeとかは普通に使うんじゃないかなあ……

>>216
減っているというか、プログラミング言語自体やメジャーライブラリが意識して取り込んできている
そう言う意味で、デザインパターンは「それそのものは減ってはいないが実装の機会は減っている」
ソースの中のコメントを覗くと「○○パターン」とだけぽそっと書いてあったりする

自分で実装しなければパターンとは言えないというなら、まあ、減るだろうな。
しかしそれは慣用句が基本語彙になったということで、デザインパターンが
真の意味で理解され始めたということなんだろう。良いことだ。

?

>>215
それらについての本出してくれたら、買うわ。