Perl オブジェクトを unblessing するということは、設計がひどいということです
か?
はいの場合、誰かが私にこれを説明できますか?
ところで、これがこの質問を引き起こした議論です。質問のコメントを確認してください
3 に答える
1 つのアプリケーションは、ハッシュ参照として実装されたオブジェクトであり
、逆参照演算子もオーバーロード%{}
したい[編集: v5.10.1 よりも古い perl もサポートしたい - そうでない場合は、単に使用する必要がありますno overloading
。]
package Foo;
use overload '+' => sub { $_[0]->get + $_[1] },
...,
'%{}' => sub { return { foo => "bar", this => $_[0] } },
...;
$foo
type を持つものについては、次Foo
のような要素にアクセスしようとすると$foo->{$key}
、オーバーロードされた%{}
メソッドが呼び出され、アクセスは失敗します。
回避策は、オブジェクトのメンバーにアクセスしている間、オブジェクトのタイプを一時的に変更し、完了したら元に戻すことです。オブジェクトの祝福を解除することでこれを行うことができますが、より頻繁に行われる (そしてより簡単に行われる) のは、オブジェクトをガベージ値に祝福することです。
sub Foo::bar { # access 'bar' member of Foo object
my $self = shift;
# $self->{bar} will invoke Foo::{'%{}'}, and we don't wan't that
my $ref = ref $self;
unbless($self); # or bless $self, 'Not::An::Object::Name'
# now $self->{bar} is accessible
my $value = $self->{bar};
bless $self, $ref; # restore object type
return $value;
}
別の例は、「Two-face-References」のセクションに記載されています。overload
別の例として、ここでこのパターンを使用します。
必要なunbless
ことは確かに眉をひそめます。オブジェクトを元のデータ構造として引き続き使用できるため、必要になることはほとんどありません。
unblessed ハッシュ参照とオブジェクトの受信にうるさいモジュールには、それほどうるさくないオプションがある傾向があります。たとえば、JSON の allow_blessed と convert_blessed です。
これは怠惰でばかげた質問です。目的はありませんがunbless
、あいまいな CPAN モジュールからランダムに選択して、なぜそれが悪い設計を反映しているのかを尋ねました。で宣言された変数の宣言を解除する方法を尋ねることもできますmy
。それは XS コードでもかなり可能ですが、明らかにばかげていることを願っていますか?
私が抱えている問題はunbless
、データ構造 (スカラー変数やファイル ハンドルからネストされたハッシュや配列に至るまで) を作成し、bless
Perl がそのオブジェクトのメソッド呼び出しを解決する方法を認識できるように呼び出したことです。
だから今、あなたはそれをしたいですunbless
。これにより、データはそのまま残ります。主な違いは、メソッド呼び出しが致命的なエラーになることです。
Can't call method ... on unblessed reference
それで、あなたは何のunbless
ためにいましたか?この致命的なエラーを発生させるために Perl に依存している場合は、この致命的なエラーを発生undef
させるオブジェクトに代入するのと同じくらい簡単です。
Can't call method ... on an undefined value
ただし、メモリが解放されるようにデータ構造が破壊される可能性があるという利点があります
より堅実なものが必要な場合は、参照がコードの複数のセクションに渡される可能性があるため、私よりも多くの人々によって信用されていない距離unbless
でのアクションの例になります