Perlについて

**デフォルトの名無しさん** · 2008/08/04(月) 20:58:41

質問スレはあるけど、Perl自身について語るスレがないので、立てました。

**デフォルトの名無しさん** · 2011/10/02(日) 00:48:53.80

> そもそもカプセル化すら出来ないMoose系を使う気にもならんが

Perlはそもそもカプセル化できない言語なんだが・・・

**デフォルトの名無しさん** · 2011/10/02(日) 00:50:03.20

EncodeとDBI以外はなくともなんとかなる。

**デフォルトの名無しさん** · 2011/10/02(日) 00:51:02.85

飛行機はなくともアメリカにいける

**デフォルトの名無しさん** · 2011/10/02(日) 00:51:57.05

それは無理だろ、そういうことを言ってるんじゃない。

**デフォルトの名無しさん** · 2011/10/02(日) 00:53:35.48

船の遅さを知っていれば、船を勧めるなんてことはしないのだが。

一つのことしか考えられない馬鹿

**デフォルトの名無しさん** · 2011/10/02(日) 00:54:38.70

>>426

{ package Mos ; use Moose; has 'x' => ( is => 'rw', isa => 'Int' ) ;}
{ package MosX ; use MooseX::InsideOut; has 'x' => ( is => 'rw', isa => 'Int' ) ;}
{ package Mou ; use Mouse; has 'x' => ( is => 'rw', isa => 'Int' ) ;}
{ package Mo ; use Moo; has 'x' => ( is => 'rw', ) ;}
{ package Obj; sub new { bless { x => 10, @_[1..$#_]}, shift } }
{
package Cap;
use Scalar::Util qw(refaddr);
my %h ;
sub new{ my $s = bless \my $o, shift; $h{refaddr $s} = { x => 10, @_ } ; $s }
sub DESTROY{ delete $hash{refaddr shift @_ }; }
}
package main;
use strict ;
use warnings ;
use Data::Dumper ;
use Benchmark qw( timethese cmpthese ) ;

cmpthese timethese ( undef, {
mos => sub { my $x = Mos->new( x => 30 ) },
mox => sub { my $x = MosX->new( x => 30 ) },
mou => sub { my $x = Mou->new( x => 30 ) },
mo => sub { my $x = Mo->new( x => 30 ) },
cap => sub { my $c = Cap->new( x => 30 ) },
cont => sub { my $c = Obj->new( x => 30 ) },
});

**デフォルトの名無しさん** · 2011/10/02(日) 00:55:24.36

技術論をしたいので、ドキュメントに書かれていない良さ
を売り込んで欲しい。

**デフォルトの名無しさん** · 2011/10/02(日) 00:55:24.23

注意
1. 型チェックなどの実装がしてない分、contが有利である
2. その代りハンデ用にカプセル化の実装を含めた => cap

cont => perl本来の記法。
cap => スタンダードなカプセル化を行なったもの。
mos => Moose
mox => MooseX::InsideOut（準カプセル化。これが実用速度なら…）
mou => Mouse
mo => Moo
#　実行結果
Benchmark: running cap, cont, mo, mos, mou, mox for at least 3 CPU seconds...
cap: 3 wallclock secs ( 2.93 usr + 0.18 sys = 3.11 CPU) @ 254233.76/s (n=790667)
cont: 3 wallclock secs ( 3.18 usr + 0.00 sys = 3.18 CPU) @ 456449.69/s (n=1451510)
mo: 2 wallclock secs ( 3.21 usr + 0.00 sys = 3.21 CPU) @ 326740.81/s (n=1048838)
mos: 3 wallclock secs ( 3.20 usr + 0.00 sys = 3.20 CPU) @ 11670.94/s (n=37347)
mou: 2 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @ 423771.94/s (n=1313693)
mox: 3 wallclock secs ( 3.20 usr + 0.00 sys = 3.20 CPU) @ 11024.69/s (n=35279)
Rate mox mos cap mo mou cont
mox 11025/s -- -6% -96% -97% -97% -98%
mos 11671/s 6% -- -95% -96% -97% -97%
cap 254234/s 2206% 2078% -- -22% -40% -44%
mo 326741/s 2864% 2700% 29% -- -23% -28%
mou 423772/s 3744% 3531% 67% 30% -- -7%
cont 456450/s 4040% 3811% 80% 40% 8% --

**デフォルトの名無しさん** · 2011/10/02(日) 01:01:31.77

418の反論/反応きぼんぬ

**デフォルトの名無しさん** · 2011/10/02(日) 01:08:16.94

反応も何も、速さと開発効率、両方の面から考えろ
速い方法が必ずしも最善ではないことは
この業界の常識だろとしかｗ

**デフォルトの名無しさん** · 2011/10/02(日) 01:10:26.54

あと、ひとりよがりの略しかたはやめろ。
コードの見やすさを全く考えていない、
他人が読むことを全く考えてない
素人にしか見えんぞ。

**デフォルトの名無しさん** · 2011/10/02(日) 01:16:58.14

モダン派が何を言いたいのかはっきりしなかったけど418を
見て思ったのは、

「青らくだ本に載っているモジュールは古いから使うな」

ってことを言いたいのか？

それならそろそろ第4版が出るから、モダン派もそうでない派も
足並みが揃うんじゃないか？

**デフォルトの名無しさん** · 2011/10/02(日) 01:17:58.54

普通にMouse使えばいいじゃん、
開発効率、Mooseと同じで速いんでしょ？

**デフォルトの名無しさん** · 2011/10/02(日) 01:20:16.62

>>437
すまんね、公開するつもりのなかった個人の導入検討メモだ。

**デフォルトの名無しさん** · 2011/10/02(日) 01:21:10.10

>>432
おい、Moose素人か？
おまじないをしてないだろ。
遅いのは当然だ。

ちゃんと調べてこい。

**デフォルトの名無しさん** · 2011/10/02(日) 01:21:55.41

Mooseでおまじないしてないと10倍の差が出るからなー

**デフォルトの名無しさん** · 2011/10/02(日) 01:23:51.94

必ず __PACKAGE__->meta->make_immutable; を書く。
書かないとか駄目。絶対。

**424** · 2011/10/02(日) 01:26:39.15

「おまじない」の存在は知らなかった（恥）
Mouseより速くなるの？

**デフォルトの名無しさん** · 2011/10/02(日) 01:28:15.29

試してみそ。

**デフォルトの名無しさん** · 2011/10/02(日) 01:37:41.25

おまじないしても、良くてもMouseの十分の一くらいの速度だ

**デフォルトの名無しさん** · 2011/10/02(日) 01:40:12.26

あらためて、MouseじゃなくてMooseを薦める理由は？

**デフォルトの名無しさん** · 2011/10/02(日) 01:40:15.79

> __PACKAGE__->meta->make_immutable;
なんかやけに泥くさいな。こんなやぼったいマジナイがいちいち必要なのか、モダーンなPerlってやつは。

**デフォルトの名無しさん** · 2011/10/02(日) 01:41:46.32

>>448
それによって、もっとめんどくさい
new実装とかのおまじないがなくせるからなｗ

**デフォルトの名無しさん** · 2011/10/02(日) 01:43:29.15

それにLarryは今、ブレスしてないんだし．．．

**デフォルトの名無しさん** · 2011/10/02(日) 01:55:34.23

例えばJcode2.xは内部でEncodeを使っている訳だけど、使うと
418は反対するの？Encodeよりも後にできたのは、便利で必要
だからだと思うんだけどな。

**デフォルトの名無しさん** · 2011/10/02(日) 02:07:18.46

>>451
Perl 5.8.0 より、Jcodeの全機能は Encode module を通じて
Perlに標準装備となります。Jcodeのメンテナンスは旧Perlのために
今後も続けていく所存ですが、最新のPerlをお使いの方には、
より高機能、高性能、そしてなんといっても標準装備の Encode の方をお薦めします

**デフォルトの名無しさん** · 2011/10/02(日) 02:13:04.12

でも便利なんだよね、Jcode。Encodeにはない良さがある。
それに内部ではお勧めのEncodeを使っているわけだし。
それともJcode相当のコードをアプリケーション内に自分で
書くのはOKってこと？

**デフォルトの名無しさん** · 2011/10/02(日) 02:16:38.97

いや、作者がEncodeの方をお勧めしますって言ってるからｗ

**デフォルトの名無しさん** · 2011/10/02(日) 02:17:40.70

それはJcode2.xがまだなかった頃の話なんじゃね？

**デフォルトの名無しさん** · 2011/10/02(日) 02:23:58.35

それにEncodeが日本語以外にも対応できるのは分かるけど、アプリ
を書くオレ自身が日本語しか対応していないわけで ^_^;
自分の読めない言語で、うっかり f*ck you みたいな出力をして
しまったら嫌だしなあ。

**デフォルトの名無しさん** · 2011/10/02(日) 02:29:15.09

モダン派も避けるPerl5.14www

**デフォルトの名無しさん** · 2011/10/02(日) 02:39:17.38

実態としては、

文字コード周り・・・Jcodeモジュール
日付まわり・・・localtime
データベース・・・DBIモジュール
フレームワーク・・・CGIモジュール
オブジェクト指向・・・bless
テンプレートエンジン・・・printf

こんなところかな。

**デフォルトの名無しさん** · 2011/10/02(日) 02:54:22.73

テンプレートエンジン・・・format
だろ

**デフォルトの名無しさん** · 2011/10/02(日) 03:26:16.98

>>455
読める？

> Jcodeのメンテナンスは旧Perlのために
> 今後も続けていく所存ですが、最新のPerlをお使いの方には、
> より高機能、高性能、そしてなんといっても標準装備の Encode の方をお薦めします

**デフォルトの名無しさん** · 2011/10/02(日) 13:41:05.10

レス不要。
このままだと、うんこカスがこびりついたパンツを履いてる様な不快感があったので。

>>432
% diff moose_test.pl moose_test2.pl
6a7,8
> { package OMos ; use Moose; has 'x' => ( is => 'rw', isa => 'Int' ) ; __PACKAGE__->meta->make_immutable ;}
> { package OMosX ; use MooseX::InsideOut; has 'x' => ( is => 'rw', isa => 'Int' ) ; __PACKAGE__->meta->make_immutable ;}
25a28,29
> omos => sub { my $x = OMos->new( x => 30 ) },
> omox => sub { my $x = OMosX->new( x => 30 ) },

**デフォルトの名無しさん** · 2011/10/02(日) 13:41:17.48

% perl moose_test2.pl
Benchmark: running cap, cont, mo, mos, mou, mox, omos, omox for at least 3 CPU seconds...
cap: 4 wallclock secs ( 3.08 usr + 0.17 sys = 3.25 CPU) @ 202104.92/s (n=656841)
cont: 4 wallclock secs ( 3.23 usr + 0.01 sys = 3.24 CPU) @ 431619.44/s (n=1398447)
mo: 3 wallclock secs ( 3.18 usr + 0.00 sys = 3.18 CPU) @ 266261.01/s (n=846710)
mos: 4 wallclock secs ( 3.19 usr + 0.00 sys = 3.19 CPU) @ 9476.49/s (n=30230)
mou: 3 wallclock secs ( 3.18 usr + 0.00 sys = 3.18 CPU) @ 329823.27/s (n=1048838)
mox: 3 wallclock secs ( 3.22 usr + 0.01 sys = 3.23 CPU) @ 8935.29/s (n=28861)
omos: 2 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @ 83636.45/s (n=259273)
omox: 3 wallclock secs ( 3.13 usr + 0.06 sys = 3.19 CPU) @ 63226.02/s (n=201691)
Rate mox mos omox omos cap mo mou cont
mox 8935/s -- -6% -86% -89% -96% -97% -97% -98%
mos 9476/s 6% -- -85% -89% -95% -96% -97% -98%
omox 63226/s 608% 567% -- -24% -69% -76% -81% -85%
omos 83636/s 836% 783% 32% -- -59% -69% -75% -81%
cap 202105/s 2162% 2033% 220% 142% -- -24% -39% -53%
mo 266261/s 2880% 2710% 321% 218% 32% -- -19% -38%
mou 329823/s 3591% 3380% 422% 294% 63% 24% -- -24%
cont 431619/s 4731% 4455% 583% 416% 114% 62% 31% --

**デフォルトの名無しさん** · 2011/10/02(日) 14:57:55.49

読めてるつもりだけど、Jcodeのおかげで食べているひとは
（数えたことないが）たくさんいるように思うし、感謝を
省くわけにはいかないな。技術論と離れてしまったがな。

**デフォルトの名無しさん** · 2011/10/02(日) 15:09:11.99

Jcodeの【全機能】は Encode module を通じて...
　　　　　　↑ここうそだよね！

**デフォルトの名無しさん** · 2011/10/02(日) 15:32:09.77

>>464
そのように書いてあるのだからウソじゃない。

**デフォルトの名無しさん** · 2011/10/02(日) 15:37:05.45

相変わらず読みにくいな。自分が読みにくいと思わないのか？
MooseX 8935/s -- -6% -86% -89% -96% -97% -97% -98%
Moose 9476/s 6% -- -85% -89% -95% -96% -97% -98%
MooseX_immutable 63226/s 608% 567% -- -24% -69% -76% -81% -85%
Moose_immutable 83636/s 836% 783% 32% -- -59% -69% -75% -81%
Capsule 202105/s 2162% 2033% 220% 142% -- -24% -39% -53%
Moo 266261/s 2880% 2710% 321% 218% 32% -- -19% -38%
Mouse 329823/s 3591% 3380% 422% 294% 63% 24% -- -24%
Old 431619/s 4731% 4455% 583% 416% 114% 62% 31% --

**デフォルトの名無しさん** · 2011/10/02(日) 15:44:01.45

単なるバカか

**デフォルトの名無しさん** · 2011/10/02(日) 15:52:18.02

重箱の隅を突くのみっともねえ。

**デフォルトの名無しさん** · 2011/10/02(日) 15:57:21.82

>>437のレスが何の意味だったが、さっぱりだったんだが、
サブルーチン名に噛み付いてたのか
少くとも434では、説明文まで付いてるのに。
単なる文盲じゃんw

**デフォルトの名無しさん** · 2011/10/02(日) 16:03:46.12

>>465
書いてあるのはおれも知ってるけど、書かれている内容が
うそだってこと。全機能がサポートされてるのならJcode2.x
は作られなかっただろ。

**デフォルトの名無しさん** · 2011/10/02(日) 16:06:33.96

個別に見ていくと粉飾がありありと浮かび上がってくるなｗ

**デフォルトの名無しさん** · 2011/10/02(日) 16:20:16.26

>>418
日付まわりとデータベースはモジュールが２つずつ書いてあるが
どう使い分けるといいの？

**デフォルトの名無しさん** · 2011/10/02(日) 16:24:33.41

>>429
アメリカ大使館か？

**461** · 2011/10/02(日) 16:37:30.45

レス不要っつったのに。
>>466
御自分でベンチ取った事無いでしょう？
どれだけ表が見辛くなるか、確認して下さい。
ttp://www1.axfc.net/uploader/File/so/69883.txt
何の為に、短めのサブルーチン名にしてるか分ると思います。

このレスにもレス不要です。

**デフォルトの名無しさん** · 2011/10/02(日) 17:35:21.23

>>470
> うそだってこと。全機能がサポートされてるのならJcode2.x
> は作られなかっただろ。

意味がわからん。
単にJcodeから乗り換えられない可哀想な人のためって
書いてあるだろ。

**デフォルトの名無しさん** · 2011/10/02(日) 17:36:43.28

>>474
CSVで吐き出せばいいだけ。
Excelで見やすくなる。

**デフォルトの名無しさん** · 2011/10/02(日) 17:37:18.27

あと、お前の命令に従うつもりはさらさらないｗ

お前は俺の命令に従って
謝る以外のレスは不要なｗ

**デフォルトの名無しさん** · 2011/10/02(日) 17:39:29.89

>>472
日付は標準モジュール or 軽いのを選びたいのならTime::Piece。
重いが高機能なものを選びたいのならDateTime

データベースは、ORMを使いたければDBIx::Class

**デフォルトの名無しさん** · 2011/10/02(日) 17:45:09.42

>>476
csv の吐き出しオプションなんざ付いてねーぞ、
態々その為にコード書くのか？

ってExcelって時点で釣り確定だろうけどさ。

**デフォルトの名無しさん** · 2011/10/02(日) 17:57:22.02

レスするなっていっただろｗ

**デフォルトの名無しさん** · 2011/10/02(日) 18:03:34.27

モダン廚は>>447に答えろ。

462は馬鹿正直に相手にすんな。
ベンチ内容に難癖付けられなくなったから、他の事でいちゃもん付けてるだけなんだから。

**デフォルトの名無しさん** · 2011/10/02(日) 18:07:10.99

ベンチ内容、Moose関係大幅に向上してるやんｗ
十分実用レベルの速度出てるよな。

MooseとMouseの違い？
MouseはMooseの機能劣化版だよ。

ってか、速度が早いことが
最善とは限らないってのは、
この業界の常識だろ。

**デフォルトの名無しさん** · 2011/10/02(日) 18:08:20.79

MooseX ＋immutable なんか
100倍になってるよね。

**デフォルトの名無しさん** · 2011/10/02(日) 18:10:09.58

かけ算も出来ないのか…

**デフォルトの名無しさん** · 2011/10/02(日) 18:11:21.73

俺の方だった。

**デフォルトの名無しさん** · 2011/10/02(日) 18:18:03.75

表の見方すら分かって無いとか

**デフォルトの名無しさん** · 2011/10/02(日) 18:29:20.71

速度の差を百分率で表示します
( (63226 - 8935) / 8935 )
100倍？？

**デフォルトの名無しさん** · 2011/10/02(日) 20:47:39.47

disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
フェースをそのまま使わなかったのか素朴な疑問なんだよ。

**デフォルトの名無しさん** · 2011/10/02(日) 20:55:37.04

思いついたままいうと、Jcode3.0とかでJcode0.xの機能もJcode2.x
の機能もEncodeの機能も実現できそうな気がするし、モダン派と
そうでない派の論争も(この件については)終結するんじゃないかと
思うんだ。

**デフォルトの名無しさん** · 2011/10/02(日) 20:59:47.99

上位互換性があると過去のバージョンとの差別化が難しいから、
キャッチコピーが使えなくなってしまうので困るってことなの
かい？

**デフォルトの名無しさん** · 2011/10/02(日) 21:05:29.13

>>488
> disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
> フェースをそのまま使わなかったのか素朴な疑問なんだよ。
おまｗアホか、もしかしてJcode知らんのか？

Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
お前、そんなんで世界各国の文字コード全てサポートする気かよ。

それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
UTF8フラグが付いたUTF8文字と決まってる。
これがPerlが理解している文字。Perlが文字と理解しているものに対して
lengthしたら、（バイト数ではなく）文字数が返ってくるし、
正規表現でちゃんと一文字として扱える。

JcodeはPerlが文字と解釈してないものを返すので
あるべき姿のPerlの使い方に適合していない。

**デフォルトの名無しさん** · 2011/10/02(日) 21:08:50.66

>>489
JcodeはJなのに世界中の
文字コードサポートするんの？

Encodeいいじゃん。なんのメリットがあるのさｗ

**デフォルトの名無しさん** · 2011/10/02(日) 21:13:17.84

まず上半分。

>Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
>お前、そんなんで世界各国の文字コード全てサポートする気かよ。

Encodeだと引数、Jcodeだとメソッドっていうだけだと思うんだけど。
この違いで何か致命的にまずいことってあるの？

**デフォルトの名無しさん** · 2011/10/02(日) 21:15:05.96

>>492
そこは分かってるからあえてツッコまないよーに。J

**デフォルトの名無しさん** · 2011/10/02(日) 21:16:20.70

え？Ｊはじぇんぶ(全部)のＪだろ？

**デフォルトの名無しさん** · 2011/10/02(日) 21:23:03.32

下半分。

>それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
>UTF8フラグが付いたUTF8文字と決まってる。

例えば (仮称)Jcode3.x にメソッドを追加して、UTF8フラグが付い
たUTF8文字を扱うのはだめなのかい？

**デフォルトの名無しさん** · 2011/10/02(日) 21:33:15.96

>>493
文字コードを変数に入れるような場合に見にくくなる。 $j->$encode

エンコード名が間違っていてもエンコード名が間違っていますのような適切なエラーが出せない。（関数がないと言われる）

エンコード名にハイフンが使えない。

ISO-2022-JP、ISO-2022-JP-2、ISO-2022-JP-3のように、
頭がISO-2022-JPで始まるものを、すべて扱うエンコーダー（Encode::JP等）が
作りづらくなる。

エンコード名に大文字小文字を無視するように作るのが面倒

Encode::from_toのように、変数の値を、”あれ”から”これ”に変換するとき
文字コードを値で渡す方がシンプル。使い方は統一すべきだ。

**デフォルトの名無しさん** · 2011/10/02(日) 21:34:30.49

>>496
Jcodeとは違う使い方をするのであれば、
Encodeでよい。

**デフォルトの名無しさん** · 2011/10/02(日) 21:44:33.79

違う使い方にちょっとずつ移行できるところが利点。

**デフォルトの名無しさん** · 2011/10/02(日) 21:48:11.88

>>499
Jcode3.0に移行してなんのメリットがあるの？
Encodeに移行してないじゃんｗ

**デフォルトの名無しさん** · 2011/10/02(日) 21:49:03.46

Jcode.pmの中身読んで、
- 後方互換のためにどれだけ苦心してるか
- どれだけ、速度を犠牲にしてるか
見りゃいいんだよ。

議論自体吹っ飛ぶぞ

**デフォルトの名無しさん** · 2011/10/02(日) 21:51:19.58

あ、たられば論の思考実験な。

**デフォルトの名無しさん** · 2011/10/02(日) 21:54:30.95

じゃあEncodeはどうやってその問題を解決してるんだ？
Encodeの作りをJcodeのインタフェースで提供するって話だぞ。

それとこれからやるかって話じゃなくて思考実験な。

**デフォルトの名無しさん** · 2011/10/02(日) 21:59:20.27

>その問題
？どの問題？

**デフォルトの名無しさん** · 2011/10/02(日) 22:01:49.32

>>503
問題を解決するために頑張ってるのはJcodeだろｗ
Perl標準の文字にあわせて作られたEncodeは凄くシンプルだ。

Perlの文字（UTF8フラグ関係）を理解できる
脳みそ程度があれば良い。

**デフォルトの名無しさん** · 2011/10/02(日) 22:03:40.98

>>503
もしかして、JcodeはEncodeのラッパーって知らないの？

EncodeのラッパーのJcodeで、Encodeを作るって
無意味だよね？

**デフォルトの名無しさん** · 2011/10/02(日) 22:06:45.35

>>504,505

Jcodeでは

> - 後方互換のためにどれだけ苦心してるか
> - どれだけ、速度を犠牲にしてるか

に苦労しているって読めたが、

> Perl標準の文字にあわせて作られたEncodeは凄くシンプルだ。

なわけで、その実装を使ってJcodeのインタフェースを提供する
ってことだよ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:08:25.67

> なわけで、その実装を使ってJcodeのインタフェースを提供する
> ってことだよ。

やっぱりお前Jcode知らんのか。

今のJcodeはEncodeの実装を使って作られたものだ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:09:18.20

もちろんJcodeのインターフェースであるがゆえに、
日本語にしか対応できなくなっている。

Encodeの劣化版がJcode

**デフォルトの名無しさん** · 2011/10/02(日) 22:11:50.54

>>506,508
知ってるってば。おれ470な。

**デフォルトの名無しさん** · 2011/10/02(日) 22:13:44.34

そして、Jcodeに新たにメソッド増やしてEncodeと
同じ事を出来るようにするぐらいなら、
普通にEncodeを使えばいい。

新しいメソッドを使う以上、使い方は全く代わるわけで
なら標準のEncodeを使えばいいからだ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:14:49.67

移行するのであれば、Jcodeを使いながら
Encodeを導入し、徐々にEncodeを使った方法に
置き換えていけば良い。

Jcode3.0なんてものを作った所で
Encodeには移行できない。

**デフォルトの名無しさん** · 2011/10/02(日) 22:19:00.72

>>511
それは現実の世界な。

503: これからやるかって話じゃなくて思考実験な。

**デフォルトの名無しさん** · 2011/10/02(日) 22:19:16.07

EncodeというかPerl開発者が推奨している
標準の文字の扱い方だな。

PerlがUnicode対応した時から
どのように文字を使うべきかが決まった。

外部からの出入り口で、内部文字コードに変換して
Perlコードからは文字はすべてUTF8フラグ付きのUTF8文字コードで
として扱う。それがPerl開発者が決めたルールだ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:22:38.39

>>513
思考実験って言葉の使い方間違ってるぞｗ

現実を否定するのが、思考実験ではない。

**デフォルトの名無しさん** · 2011/10/02(日) 22:24:36.48

仕様と実装を分けて考えればいいんじゃないかと言ってる
訳なんだけど、どうしても切り離せないような話が返って
くるなあ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:24:51.08

思考実験ってｗｗｗ

単に考えるだけで作らないって言ってるだけやんｗ

**デフォルトの名無しさん** · 2011/10/02(日) 22:26:42.93

>>517
そのとおり。なので暇なひとだけレスして欲しい。

**デフォルトの名無しさん** · 2011/10/02(日) 22:27:46.67

>>516
なら答えは簡単だ。

機能の多いもの（全世界対応）から
機能の少ないもの（日本語専用）は作れるが、

機能の少ないもの（日本語専用）から
機能の多いもの（全世界対応）は作れない。

ならEncodeモジュールを基本とし、
Jcodeはそのラッパーという仕様が一番良い。

**488** · 2011/10/02(日) 22:35:29.35

>>disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
>>フェースをそのまま使わなかったのか素朴な疑問なんだよ。

なんか、488の回答の下地がようやく整ってきた感じがする。

>>519
その話の続きを聞かせて欲しい。

**デフォルトの名無しさん** · 2011/10/02(日) 22:37:34.33

>>520
>488の回答であり続き。

おまｗアホか、もしかしてJcode知らんのか？

Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
お前、そんなんで世界各国の文字コード全てサポートする気かよ。

それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
UTF8フラグが付いたUTF8文字と決まってる。
これがPerlが理解している文字。Perlが文字と理解しているものに対して
lengthしたら、（バイト数ではなく）文字数が返ってくるし、
正規表現でちゃんと一文字として扱える。

JcodeはPerlが文字と解釈してないものを返すので
あるべき姿のPerlの使い方に適合していない。

**デフォルトの名無しさん** · 2011/10/02(日) 22:41:37.51

おれとしては521よりも519のほうが知りたかったことに近い。

うまく聞き出せなかったけど。

**デフォルトの名無しさん** · 2011/10/02(日) 22:43:33.28

つか、JcodeがEncodeのラッパーになっている理由なんて
初心者プログラマでないなら、自然と理解できるはずなんだがｗ

逆にJcodeのインターフェースのままにしようなんて
思う奴はいないだろ。

**デフォルトの名無しさん** · 2011/10/02(日) 22:50:03.72

519の話の続きにはとても価値があると思っている。でもそれは521
なんかじゃない。うまく質問ができるようになったら、教えて欲しい。

**デフォルトの名無しさん** · 2011/10/02(日) 22:53:12.08

>>524
と言われてもどっちの書き込みも俺だし
>>519の続きは>>491以外のの答えなんて無いよｗ

**デフォルトの名無しさん** · 2011/10/03(月) 01:43:37.06

おまえら熱いな