Perlのオブジェクト指向って無理やり実装だなw
■ このスレッドは過去ログ倉庫に格納されています
いまさらだが、後付感たっぷりでワロタ
PHPの方がはるかに自然な形で実装しているわ。
なんだろうね。言語仕様の説明=内部実装の説明になっていて
使うためではなく、言語の勉強のための言語だなぁと思った。 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 速度 PHPのオブジェクト指向も後付けなのに、誰も突っ込まないのな。
そんなもんか。 寧ろ後付でも酷くてもみんなが使いたがるperlの魅力に気が付いて欲しいw PHPのオブジェクト指向はごく普通だからな。ほとんどJava。
Perlの場合はクラスベースじゃないから。JavaScriptとかもそうだけど。 本当はオブジェクト指向とかエロいこと考えなくてすむのがお気楽LL言語だったのかもしれない。 >>168
Perlは分類上クラスベース。
Javascriptのようにインスタンス単位でメソッドを増やしたりする芸当はできないよ。
データメンバは増やせたりするけど。 先を行く者を背中から撃つ者は、後から来る者に背中から撃たれる。 インスタンスにメソッドを追加するのはRubyも出来る 完全にオブジェクト指向であっても変数名に接頭辞が付かない言語は苦痛だ
i とか s とか付けりゃいいんだろいけど、やっぱ接頭語として記号があると楽かな Rubyの場合、メソッドの()を省略できるから、メソッドなのか変数なのか区別がつかない。素直に()を強制すればよかったのに。 Perl のオレオレるーる - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech
http://subtech.g.hatena.ne.jp/cho45/20080818/1218995299 わからん・・・
わざわざシフトキーを多用したいなんて・・・ Rubyの[]もメソッド名というのは、作者の無意味な自己満足に過ぎないと思う。 実際 Perl の オブジェクト指向は Ruby だし >>182
data['hoge'] の動作を自前で設定できたらいいなと思ったことはないかい
data['hoge'] でも data['Hoge'] でも data['HOGE'] でも data[:hoge] でも data の hoge が呼べたらいいなとか
あと、メソッドだからプロファイラで Hoge#[] の使用回数がきちんとカウントされるぞ
ていうかこのへんは普段は意識することないし「実はメソッドだったんです!」「うわ徹底ぶりキモっ!」でいいとは思う あの Perl の後付け感は最高。
僕は、あの屋上屋を架すみたいに積み上げたり、既存文法の意義の変更とかで、
済し崩し的に拡張して行くあのゴチャゴチャ感が Perl らしくて好きだよ。
C++ も似た感じで好きだ。 perlでやる程度の処理にoopなんぞ手間が増えるだけだから後付け仕様で十分
最近は車輪探す手間のほうがでかくなってるしな >>188
まったく同意見だ。C++が好きな理由も同じ。 >>187ハッシュやリストの拡張クラス作ればいいだけじゃん。
[]がメソッド名なら、arr[1] = 'a'はarr.[](1,'a')こんな感じに書くべきだけど、それじゃ変だからローカルルールででっち上げてるわけでしょ。
その勝手な感じについていけない。 別にメソッドとして書いてもいいよ(そっちのほうが計測不能なレベルでわずかに速い)
Ruby から見れば、for 文 と each メソッドの関係のような単なるシンタックスシュガーに過ぎない
irb> h = Hash.new
irb> h.[]=('key1','value1')
irb> p h
{"key1"=>"value1"}
irb> p h.[]('key1')
"value1"
誰も array[i] 形式や hash[key] の使用を勧めてはいないぞ
記号だけのメソッドが気になるなら、Array#push や Hash#store を使うといい 松本がいつも言うシンタックスシュガー、都合のいい言い訳にしか聞こえない。Railsもそうだけど、ユーザの感じる押しつけられ感が凄い。
初めてPerl触って思ったこととか - ずっと君のターン
ttp://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/technohippy/20080903%231220457999
Railsの記述上の違和感はRubyではなくRails記法によるもの
Rubyは関係ないし、RailsのDSLっぽい無茶な書き方を嫌がってる人は少なくない >>1 は、
>PHPの方がはるかに自然な形で実装しているわ。
って言ってるけど、PHP って他の組み込みの機能が何となく不自然な気がする。
何というか、統一感のないユーティリティ・ライブラリって感じ。
(だったような。ちょこっと触っただけだからかもしれないけど。
まぁ、PHPは言語と言うよりツール色)
Perl 5 の OOP は、確かに他の言語の OOP 機能からの見方で見ると不自然に見えるけど、
Perl 言語からの見方で見ると、とても自然に見える。
それに、専用の文法でがちがちに固めていなくて、幾つかの機能の組み合わせで実現するやり方は、
見方によっては美しくも感じる(Unix っぽい美学)。 PHPって、せっかく例外の仕組み備えたのに、なんで組み込み関数は例外を投げないんだろう。 それは、C++は例外の仕組みあるのに、
なんで組み込みの関数(fopenなど)は例外を投げないんだろう。
といっているのと同じことだぞ。 ■ このスレッドは過去ログ倉庫に格納されています