Perlのオブジェクト指向って無理やり実装だなw
■ このスレッドは過去ログ倉庫に格納されています
いまさらだが、後付感たっぷりでワロタ PHPの方がはるかに自然な形で実装しているわ。 なんだろうね。言語仕様の説明=内部実装の説明になっていて 使うためではなく、言語の勉強のための言語だなぁと思った。 >>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以外のスクリプト言語はどれも大差ない。 コード規約で何とかしないで Pragmaでも作ってほしいね。 $_ の使用を禁止するとか $_ は可読性の低下を招くので使わないようにしてる $_を使わないことで可読性は上がるだろう しかしそれだったらrubyかPHP使う $_ の問題だけで Perl を使わない理由にはならない 同じ変数を使いまわさない。 つまり、一つの関数内で同じ変数名の変数を 違う目的に使わないって事だけど、 これ、言語に限らずコーディング規約としてでてくる。 多分だれしも納得がいく理由だろう。 $_ はそれと同じ問題をはらんでいる。 変数名にはわかりやすい名前をつけましょう。 Perlはstrictプラグマが標準で、変数を宣言して使うから、不用意に変数を初期化したり、ゴミとして残ることがない。 局所化されてるから、安心して同じ変数名を使いまわしていい。 他の言語のように、条件分岐やループの深いところで突然多次元配列に値を入れたりすることがないし、実行されない処理についてもコンパイラがエラーを検知してくれるから、発生しづらい条件のエラーがすぐにわかる。 ただ、strictプラグマはPerlのコード品質を押し上げているわけだけど、KENTのCGIレベルのプログラマーからだとジャンプアップが大きく、初級のプログラマーがPHPに流れる原因にもなってる。 が、PHPはどう書いてもそれなりに動いてしまうばっかりにレベルの停滞を招いてるという面もある。 Perlのファニーレターは、可読性を上げる点でも役立ってる。 Perlでは普通こう書く。 foreach $data (@data) { print $data; } PHPでは、こう書くしかない。 foreach ($data as $tmp) { print $tmp ; } あるいは、こうしてみたり。 foreach ($data_list as $data) { print $data ; } 変数名からだけでデータ型が分かるのがPerlの可読性の高さ。 foreach $data (@data) { print $data; } って何か気持ち悪いんだよな・・・ でいつもこうしてます foreach $data (@datas) { print $data; } >>139 そう言われると俺も @data とか @file とかにしてたwww あなたはやっぱり @lists とかにしてるの? リストそのものが複数形だとおもうんだけど 。。。 あれ違うか?w >>138 > Perlのファニーレターは、可読性を上げる点でも役立ってる。 > Perlでは普通こう書く。 > foreach $data (@data) { > print $data; > } foreach my $datum (@data) { print $datum; } >>141 > あなたはやっぱり @lists とかにしてるの? foreach my $elem (@list) { print $elem; } ナドト 名前空間が別なのではない。変数のスコープが別なのだ。 $tmpとか$nとか$iとか、数行のブロック内でしか使わない一時的な変数のためにイチイチ長ったらしい変数名を使うのは可読性が下がる。 コードの大事なポイントをぼかしてしまうから。 変数名やらコーディング規約やらはPerl Best Practicesを読むといいですよ 書いてあることがすべて正しいとは思わないけどbetter practiceが見つかるのは間違いないです >>139 dataは既に複数形で、単数形はdatum云々、、、、 >>141 >>143 >>147 ああ、俺がアホだった・・ dataの時はdatumを使います でもいつも厳密には考えてなく my @dates = localtime; my $date = sprintf '%04d/%02d/%02d', $dates[5] + 1900, $dates[4] + 1, $dates[3]; のような事もしちゃってます。こっちのが気持ち悪いか・・・ Perl6では@date[1]のように参照出来るらしいから感覚的に少しはマシになるのかも 横レスすると手を抜いて配列に入れるんじゃなくて スカラーでもハッシュでもいいから名前付けたほうが見やすいわかりやすいのは明白 PerlからPHPに移ってからは@を使う妥当性が全然わからなくなった。 @rrayとか$calarてのはやめて欲しいないな。これもPerl文化か? >>私はこれで Perl から乗り換えました。 この程度では乗り換えるに値しない まぁ、Switch Case 文はデフォで欲しいですがw >>156 givenとwhenでよければありますよ。 バージョン5.10以上ですけど。 変数には記号がある方が分かりやすい。 PHPみたいにデータ型によらず同じ記号であっても。 JAVAとかC#みたいにIDE前提でカラーリングされてればなくても良いけど。 その点じゃRUBYが一番見づらい。 変数という意味で記号をつけるのはわかるが、 配列やスカラーやハッシュを区別する為の記号ってのは 意味がわからない。 他の言語を見ればわかるように、そんな区別なんかしなくても 問題なく実装できてるじゃん。 ハンガリアン記法見ても分かるように、変数名からデータ型が分かれば可読性が上がる。 可読性とコーディングをいうまえに明示的に宣言できる構造体をくれ ruby perl 比較 python ruby perl ruby perl 違い ruby perl php ruby perl 速度 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる