Perlのオブジェクト指向って無理やり実装だなw
■ このスレッドは過去ログ倉庫に格納されています
いまさらだが、後付感たっぷりでワロタ PHPの方がはるかに自然な形で実装しているわ。 なんだろうね。言語仕様の説明=内部実装の説明になっていて 使うためではなく、言語の勉強のための言語だなぁと思った。 >>31 PHPユーザーの方がキモいから安心しろ。 >>30 クラスに書いたら、クラス単位だけど? ねぇ。PHP知っている? 正直、rubyやpythonがここに上がらないのは当たれ前なんだよね。 むしろ、PerlやPHPの拡張によってOOPを強引にでも実現してきたことを誉めてあげたい。 バカにするけど、PHPなんて、 OOPだけ見れば、結構良く実装できてると思うよ。 Perlは、もうちょっとだけど……。 普通の言語は変数のスコープはブロック単位なんだよ。 PHP以外の言語をやったことがあればすぐに分かること。 oopの話題でoopが得意じゃない人のブログ出すとかwww おや、スコープの話で不利になったから、オブジェクト指向の話に戻すんですねw PHPは5でもネームスペースが無いから 正直使い物にならない。 C/C++,Java,VB,C#もブロック内でレキシカル変数を作れる罠。 JavaScriptは? っていうか関数レベルのスコープがあれば ブロックレベルのスコープは無くても良いなぁ。 おれ、そんなに長い関数書かないしw Perlでクラスを使ってみたいが、 毎回コンストラクタを自力実装するのが面倒で。 コンストラク作るのは面倒じゃないだろ。その仕組みを理解するのは面倒というか大変だが。 >>1 比較相手にPHPを持ち出し、しかもPHPの方がマシって…wwwww PHPは糞中の糞 >>51 サーバサイドスクリプトとして比較するならPHPの方が上に決まってんじゃん まあ、PHP以外の、PerlとかRubyとか知ってる人にとっては、PHPの低機能はつらいものがあるよ。 初心者が書いても、上級者が書いても、同じようなコードにしかならないんだから。 プログラム書いててこれほどつまらない言語はない。 ふむ、同意だけど もしかしたらそれで逆に 保守性の水準を確保してたりしてな コードを書くことが目的なんでしょw $_ みたいな同じ名前の変数ばかり多用する 醜いソースかいたりなw Javaのように厳密に書くことも出来なければ、PerlやRubyのように記述性が高いというわけでもない。簡単だから覚えるのは速いのが唯一の長所。それがPHP。 でもまあ、クラスの定義を 普通に class キーワードを使って かけるのはすばらしいと思うよ。 class Foo extends Bar { private $a; function __construct() {} function func() {} } $foo = new Foo(); $foo->func(); オブジェクト指向を知っている人なら誰だってすぐわかるでしょ? 自然なオブジェクト指向。 クラスベースOOPの書法が大好きなのは判わんでもないけどさ そもそもクラスベースってほんとに良いものなのかとか語られる昨今だしな ECMAScrips3rdの単純さと汎用性の兼ね合いなんか絶妙だしな うん判るのよそれは boost触っててクラスとかもうどうでもよくね見たいに 脳味噌が腐った豆腐になってる馬鹿の戯れ言です rubyやpythonその辺の手懐けかた上手いよな perlにはこの際、我が道突っ切ってもらった方が面白そうな 文法は一番PHPがわかりやすいというか、自然だわな。CやJavaやPerlなんかを知ってれば、特別学習しないでもだいたい予測つく。 つか、OOPの書き方そのものの参考文献が少なすぎるんだよ。 ・OOPとは……知ってるから! ・言語XXXでOOP……基礎過ぎるから! ・言語XXXでデザインパターン……急に高度過ぎるから! もっと、初・中級者向けのOOP書き方入門が欲しいですよ。 オブジェクト指向Perlマスターコースだって? あんなの日本語じゃねーよ(読破したけどさw) >>64 >・言語XXXでOOP……基礎過ぎるから! >・言語XXXでデザインパターン……急に高度過ぎるから! そこは別に飛躍してなくね? OOPの基礎が判ったら、ちょっと実践パターン見て行きましょうか…… という流れだし 逆にどうしろと。 単に、実感湧かないってことかもしれないな。 Perlじゃないけど、俺はるびま出張版として出版された「正しいRuby コードの書き方講座」が言語問わず参考になった。 他人の成果物の設計に駄目出ししまくるだけの本wなので、妙に実感あったw 青木に煽られない程度のコードを保ちたいなという、欲求が探究心に繋がった感じ。 ああいう傾向の本、言語問わず他にねえもんかな。 >あんなの日本語じゃねーよ(読破したけどさw) 逆に読みたくなるぜ、その感想w 多分おれはヘン >>65 たぶん、分かってるとは思うけど、 OOP基礎 → デザパタ本は、急に難しくなりすぎだよ。 OOP基礎本は、本当に基礎の基礎しか書いてないもん。 その方向は間違ってないんだけどさ。 その間を埋める本がないんだよ。 つまり、>>65 のいう「正しいRubyコードの書き方講座」や Periで言えば、宮川氏のML(いつものことながら途中で飽きやがった!)のような。 デザパタってある程度実践詰んでないと、 意味……というかメリット理解できないじゃん。 Ruby触ったこと無いけど、最近本も充実してきたし、手出してみるかな。 しかし何でPHP5は寸前のところでnamespaceをなくしてしまったのか。 クラス名をアンダーバーで繋げるという回避策は悲しすぎる。 唯一悔やまれる点だわ。 そんなにネームスペースって必要かなぁ? アンダーバーでつなげればいいだけでしょ? >>70 えっ? (ネームスペースがあるほかの言語で)ネームスペースの部分省略してるの? もし名前がかぶったらどうするの? ネームスペースがない、パッケージがないのは、PHPにろくなクラスライブラリがない理由の一つだな。 好き勝手にファイル名やクラス名をつけるから、使いまわしが利かない。 PHP5.3からnamespage復活するのってホント? 目次 - oreilly.co.jp -- Online Catalog: 初めてのRubyより 1章 ようこそ、Rubyのある生活へ 1.1 Rubyの特徴 1.1.1 オブジェクト指向言語 1.1.2 より良いPerl http://blog.livedoor.jp/dankogai/archives/51077051.html >>72 >ネームスペースがない、パッケージがないのは、PHPにろくなクラスライブラリがない理由の一つだな。 それは探せる頭が無いだけ。 ネイティブインストールしなきゃ使えないPerlモジュールより、よっぽど充実してて汎用も効くクラス多いよ。 PHPにまともなクラスライブラリなんてないよ。あるのは膨大な組み込み関数とあまたあるフレームワーク付属のヘルパークラスだけ。 まともなクラスライブラリが無い。ってことは 足りないクラスライブリががあるってことだよな? その足りないクラスライブラリ、いってみて。 少なくともPearにあるライブラリのPHP5・E_STRICT対応版 もしかしてここ間違ってないですか?っていう程度。 意図的にそうしているのなら問題ない。 本来ZendフレームワークがPearを引き継ぐはずだったけど、そうはなりませんでした。 2-3号前のWEB+DBプレスの座談会に書いてあったけど、普通そこそこPHPやってると飽きる。他の言語に行く。だから、ユーザコミュニティのレベルが一向に上がらない。 >>86 それは飲み屋での雑談よりも信頼すべき話なのか? 小山哲氏って日本のPHP界じゃトップクラスの有名人だと思うけど、PHPのダメさをあれだけ自覚して語ってるのにはちょっと好印象を持った。仕事として割り切ってるんだろうな。 Ruby 及び Perl におけるクラスの生成について。 http://b.hatena.ne.jp/entry/http ://tomato.or.tp/programming/memo/class/class.html >>88 > 小山哲氏って日本のPHP界じゃトップクラスの有名人だと思うけど だれ? デイトレーダー? 日本の歴史学者? ぐぐってもわからないや。 日本のPHP界っていうほどのコミュニティがあるの? 344 :デフォルトの名無しさん:2008/07/18(金) 00:56:41 >>334 同意。 PerlのEncodeは終わってる。 言っておくが、自分には使える。 Perl好きだし、Encodeモジュールもわかっているつもり。 ただ、そこまでPerlにはまっていない周りには使えないし、わかってもらえない。 これが致命的。 (よくはまるのは、UTF-8フラグのついた文字列と バイト列としての UTF-8文字列の違いとかのあたり) それに、ソースコードを UTF-8 で書くと、システムがローカルエンコーディングの場合 ファイルを開いたりするのさえ面倒。 Unicode がらみのスクリプトを書くたびに、 sub e { Encode::encode('cp932', $_[0]) } sub d { Encode::decode('cp932', $_[0]) } sub E { map { Encode::encode('cp932', $_) } @_ } sub D { map { Encode::decode('cp932', $_) } @_ } ↑こんなのを上に貼って、 open IN, e"日本語.txt"; とか書いたり、デバッグする時に b 30 ($str eq d"日本語") とかやったりしてるけど、正直言って超バッドノウハウ。 人が見てもやっぱりわからないし。 UTF-8フラグの存在がUnicodeの扱いをかなり複雑にしているよな。 なんでそんなものを作ったのか理解できない。 他の言語にはそんなもの無くてもうまくやっていけてるじゃないか。 > PHPだと全部mb_に差し替えないと行けない。 見てのとおり、すごくわかりやすいルールです。 一方Perlの場合・・・複雑すぎて ここでは説明し切れません ;; 複雑者ねー世。外人が作ったライブラリでも日本人が作ったライブラリでも透過的に扱える。 ただし、外人が作ったライブラリがUTF-8(UTF8フラグ)を考慮して ちゃんと作られている場合は。だろ? 最近でたオブジェクト指向Perlの本ってアルパカ本と比べてどうなの? Encodeは始め面倒だな〜と思ってJcodeに逃げてたけど使い慣れてくるとしっくりとくる。 そりゃPerl標準なんだからしっくりこないとダメだろw 問題は、慣れないといけないような仕様だってことだ。 別にJcodeで済むんだったら、Jcodeでもいいけどな。 「美しいコードを書けるからRubyを選んだ」---Ruby on Rails作者 David Heinemeier Hansson氏:ITpro http://itpro.nikkeibp.co.jp/article/NEWS/20060620/241346/ DHH:いろんなPerlソースを見ていると,頭が爆発しそうでした。 なぜかというと,どのコードを見てもスタイルがそれぞれ違って, 正しいのはどれかがわからない。 それぞれおもしろいんだけど,自己主張が激しすぎると感じました。 一方で,Rubyで書いたものはどれも, 同じことをする場合はだいたい似たように見える。 この「統一感」がすごく重要でした。 >>104 Perlは確かにひどいが、Rubyも大して統一感なんてないけどな… Perlはひどい書き方ができるけどきれいに書こうと思えば書けるだろ。 strictプラグマを使えば、PerlはLLの中で一番厳密なコーディングを強制される。 PHPなんかだと、コンテントタイプヘッダが自動で出力されるとか、最近は減ったけどregister globalsがオンになってるせいで、それこそやりたい放題に書いてもそれなりに動いてしまう。 多分、書き慣れたPerlが怪奇に見えるのは、関数に()が省略できたり、returnを省略できたりするところだと思うんだけど、それはRubyも一緒だよね。 >書き慣れたPerlが怪奇に見えるのは、関数に()が省略できたり、returnを省略できたりするところだと思うんだけど そんな些細なところじゃないと思うんだけど $@とか$/とかの特殊変数はたいした問題じゃない。使うのは限られてるし、そういうもんだと思えばどうってことない。忘れたら、調べればいいだけ。 isset()なのかis_set()なのか忘れてしまうのと変わらない。 正規表現とか$_なんかは奇妙に見えるな。 for(1..40) { print $_ . "..aho\n" if /3/; } おっとECMAScriptの悪口はそこまでにしてもらおうか >>110 いろんなものを省略できるところ。 コンテキストという概念 bless UTFフラグ perlは記述するコードをUTF8(BOM無し)固定にすりゃいいんだよね そうすりゃちったぁラクになるべ? コンテキストを省略、blessを省略、何のことだ? Perlは複雑なデータ構造を表す場合、リファレンスを使う必要があり、リファレンス・デリファレンスで記号が長く続き、読みづらくなるというのはある。 すべてを順番付きのハッシュで済ませらるPHPと比べると、断然見づらい。 が、仕事でプログラムをするような人間が、Cのポインタが分からないとか、Perlのリファレンスが分からないとか、論外だな。 趣味のプログラマーにとってPerlが難解だというのはそうかもしれないが。 おそらくUTF8の話は、ム板から得た知識だろうが、マルチバイトを扱う時にUTF8フラグをつける、出力するときに外す、だけでいいことだ。 そもそもUTF8フラグのせいで、ソースが読みづらくなるなんてことは有り得ない話。 >>118 本当にそれだけなら、内部で勝手にやってくれという話。 なんでコードでUTF8フラグをつけたり消したりする命令があるのか。 それはUTF8フラグあるせいで、いろんなライブラリが、 UTF8フラグをつけていたり、つけていなかったりするから。 UTF8フラグの存在がなければ、そんな混乱は起きないんだがな。 >>117 仕事だから、難解なものでもやれというのはわかる。 だが、今はやるかやらないかの話はしていない。 難解なのか、難解ではないのかの話。 答えは出ている。難解だ。 だからどこら辺が難解なの? PerlのOOなんて変数に名前空間結びつけただけだろ フラグついてりゃ3byte文字も1文字換算だし ついてなけりゃbyte単位だから処理違うしな inしてきたものにはかならずフラグつけてoutのときにはずせば混乱はない decode, encodeってのがちょい紛らわしいネーミングだとおもうけど 明示的にデコードしなくてもフラグ付くことがあるのが問題。 暗黙的なスタイルと明示的なスタイルが混在して、もうわけわかめ。 もともとの話はPerlのソースコードが読みづらいかどうかだから。 UTF8フラグとソースコードの読みづらさは関係ないし。 それってスタイル、好み、技量の問題じゃないの? 読む側、書く側、双方ともに >>107 それをプロジェクト内のPerlプログラマ全員にやらせてみろよ 色んな書き方が出来る反面 「自分の書き方」 をもてない奴がコピペばかりしたり、 サンプルを自分の書き方に直せない人が多いだけなんだと思う まぁ利用者が多いゆえの弊害だと思う >>127 それはPerl以外の言語にもいえる事では >>129 Perlは他言語に比べ突出してると思う。 でもコード規約でなんとかなる。 PERLの記述性はそのままRUBYにも当てはまる。 JAVAみたいな型の指定を強制してステップをかける言語の方が記述性が低い分、統一感は高いと思うが、PYTHON以外のスクリプト言語はどれも大差ない。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる