2013-07-28 5 views
21

EXPORT_OKEXPORTの違い/使用例は何か分かりません。
ほとんどのリソースはのラインで何かを言及:perlのexportとexport_ok

@Export標準のインポート方法を使用して ユーザーの名前空間に、モジュールの関数や変数をエクスポートすることができます。この方法では、我々は モジュールのメンバーにアクセスするためのオブジェクトを作成する必要はありません。
@EXPORT_OKは、モジュールのシンボル(サブルーチンと変数)の選択リスト のオンデマンドベースのシンボルのエクスポートを行います。

しかし、私は実際には違いはありません。
誰かがこの2つのシンボルの違いや使い方の小さな基本的な例を提供してもらえますか? fine Exporter manualから

+0

シンボルがあれば、デフォルトで多くのシンボルをエクスポートするべきではありません。 @EXPORTは通常小さいか空です。 @EXPORT_OKにははるかに多く含めることができます。例えば、Encodeは、デフォルトで( '@EXPORT')の' encode'と '' decode'をエクスポートしますが、 '' is_utf8''( '@EXPORT_OK')はエクスポートしません。 – ikegami

答えて

15

  • use YourModule;
    これはYourModuleの@EXPORT使用文の名前空間にからすべてのシンボルをインポートします。
  • use YourModule();
    これにより、perlはモジュールを読み込みますが、シンボルはインポートされません。
  • use YourModule qw(...);
    これは、発信者によってリストされたシンボルのみを名前空間にインポートします。表示されているシンボルはすべて@EXPORTまたは@EXPORT_OKでなければなりません。そうでないとエラーが発生します。 Exporterの高度なエクスポート機能は、このようにアクセスされますが、シンボル名と構文的に異なるリストエントリがあります。

あなたが@EXPORTを使用すると、誰かがいつものuse YourModule;を行うのであれば、あなただけの@EXPORTにすべてを自分の名前空間を汚染しました。しかし、@EXPORT_OKを使用する場合は、モジュールを使用している人が名前空間に何が起きるかを制御できるように、モジュールをインポートするよう具体的に要求する必要があります。

違いは本当にuse Rの名前空間に入ったものを制御誰の問題です:あなたは@EXPORTを使用している場合、その後use D中のモジュールは、あなたが@EXPORT_OKを使用する場合、コードは、インポートを行うと、自分の名前空間を制御しません。もちろん

、あなたは常にあなたの名前空間を汚染から失礼モジュールを維持するためにuse Whatever();を言うことができるが、それは醜いだとあなたはすべてのあなたの名前空間の上に走り書きしたい失礼なコードの周りにその場しのぎする必要はありません。

+0

' YourModule qw(ab); 'と' @EXPORT qw(ab ); 'は意味がありませんか?そうでなければ私はなぜ '@ EXPORT_OK'が必要なのかまだ分かりません。 – Jim

+3

@Jim' our @ EXPORT'はあなたがデフォルトで(つまり 'use YourModule;)でエクスポートするシンボルを保持します。これを行うことは、悪い習慣*とみなされます。 '@EXPORT_OK'は、明示的な要求でエクスポートできるすべてのシンボルのリストを保持します。 – amon

35

たとえば、@EXPORTを使用するMyPackageというパッケージがあります。今

#this is MyPackage.pm 
package MyPackage; 
@EXPORT = qw(do_awesome_thing); 

sub do_awesome_thing { ... } 

sub be_awesome { ... } 

、私は私のコードでMyPackageを使用し、

#this is myscript.pl 
use MyPackage; 

do_awesome_thing(); #works 

be_awesome(); #doesn't work 
MyPackage::be_awesome(); #works 

do_awesome_thingは自動的に私は「私にこれを与える」と言ってなくても、MyPackageから私のコードにエクスポートされます。 be_awesomeはエクスポートされていません(@EXPORT_OKと一緒にエクスポートされません)。私は「エクスポート」が私たちに与えるものについて明確にするためにその部分を示しています。

一方

、私は@EXPORT_OKを使用するパッケージMyOtherPackageを持っている場合は、

#this is MyOtherPackage.pm 
package MyOtherPackage; 
@EXPORT_OK = qw(do_awesome_thing); 

sub do_awesome_thing { ... } 

sub be_awesome { ... } 

して、直接do_awesome_thingを呼び出す行は動作しません

#this is mynewscript.pl 
use MyOtherPackage; 

do_awesome_thing(); #doesn't work 
MyOtherPackage::do_awesome_thing(); #works, as always 

してみてください。これは、@EXPORT_OKの中に何かを入れると、「要求した場合にのみこれを私のユーザに与えてください」と書かれているからです。ここではdo_awesome_thingを明示的にインポートせずにuse MyOtherPackageと言っただけなので、インポートされず、パッケージ名を指定することによってのみアクセスできます。

do_awesome_thingをインポートする方法は、上記のmynewscript.plの2行目のuse MyOtherPackage qw(do_awesome_thing)となります。これはそのモジュールをインポートし、do_awesome_thingを直接利用できるようにします。その後、上記のmynewscript.plの4行目が機能し始めます。

use MyPackage qw(do_awesome_thing)も最初のパッケージで指定できます。この場合、@EXPORTリストの他のものはエクスポートされません。do_awesome_thingのみになります。したがって、デフォルトのケースであるuse PackageName;を除いて、@EXPORT@EXPORT_OKは同様に動作します。デフォルトの場合、@EXPORTの内容は自動的にユーザーのスクリプトにスローされますが、@EXPORT_OKはより丁寧で何かをエクスポートしません。

+4

* @EXPORTでは、2つの選択肢があります。ただ間違っている。 '@ EXPORT'と' @ EXPORT_OK'はほとんど同じです:どちらの場合でも、ユーザはインポートしたい名前のリストを指定することができます。ユーザーが*インポートする名前のリストを*提供していないときに起こることとは異なります。その状況では、 '@ EXPORT'のものがエクスポートされ、' @ EXPORT_OK'のものはエクスポートされません。 – tobyink

+1

@tobyinkおかげさまで、EXPORTで働いていないので、それを知らなかったので、私はその部分を今変更しました。私がこのO'Reillyの本(http://docstore.mik.ua/orelly/perl/advprog/ch06_05.htm)に出会ったことは、これを確かめるためにグーグルで書かれていましたが、同じミスを犯しているようです。「モジュールがEXPORT EXPORT_OKではなく、インポートリストに記載されているかどうかにかかわらず、エクスポートされたすべてのシンボルが取得されます。 しかし、私はその行動をテストし、あなたが正しいと本(明らかに)間違っていることを確認しました。 – sundar