«

Please give me your advice
I was reading perltoot document, and I got stuck the following class
global variable concept.
HELP!!

Why global variable should be accessed by hash like this? :
$self->{"_CENSUS"}

Perltoot doc:
Accessing Class Data
It turns out that this is not really a good way to go about handling
class data. A good scalable rule is that you must never reference
class data directly from an object method. Otherwise you aren't
building a scalable, inheritable class. The object must be the
rendezvous point for all operations, especially from an object method.
The globals (class data) would in some sense be in the "wrong" package
in your derived classes. In Perl, methods execute in the context of
the class they were defined in, not that of the object that triggered
them. Therefore, namespace visibility of package globals in methods is
unrelated to inheritance.(WHAT THE HECK HE IS TALKING ABOUT @.@??????)

Got that? Maybe not. Ok, let's say that some other class
"borrowed" (well, inherited) the DESTROY method as it was defined
above. When those objects are destroyed, the original $Census variable
will be altered, not the one in the new class's package namespace.
Perhaps this is what you want, but probably it isn't.
(WHAT THE HECK HE IS TALKING ABOUT @.@??????)

jh3an <> writes:

> Please give me your advice
> I was reading perltoot document, and I got stuck the following class
> global variable concept.
> HELP!!
>
> Why global variable should be accessed by hash like this? :
> $self->{"_CENSUS"}

Note that that's not just a hash, $self is an object, and
$self->{_CENSUS} in the original text is a reference to a shared lexical
variable, not a package variable.

> Perltoot doc:
> Accessing Class Data
> It turns out that this is not really a good way to go about handling
> class data. A good scalable rule is that you must never reference
> class data directly from an object method. Otherwise you aren't
> building a scalable, inheritable class. The object must be the
> rendezvous point for all operations, especially from an object method.
> The globals (class data) would in some sense be in the "wrong" package
> in your derived classes. In Perl, methods execute in the context of
> the class they were defined in, not that of the object that triggered
> them. Therefore, namespace visibility of package globals in methods is
> unrelated to inheritance.(WHAT THE HECK HE IS TALKING ABOUT @.@??????)

That part relates to the "Class Data" section directly above it. Maybe
you should read that again.

> Got that? Maybe not. Ok, let's say that some other class
> "borrowed" (well, inherited) the DESTROY method as it was defined
> above. When those objects are destroyed, the original $Census variable
> will be altered, not the one in the new class's package namespace.
> Perhaps this is what you want, but probably it isn't.
> (WHAT THE HECK HE IS TALKING ABOUT @.@??????)

<MS Paperclip>It seems you're having trouble grasping the potential
problems with inheritance. Maybe you should just try and build some
inheriting classes and objects and you'll find out</MS Paperclip>



--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

jh3an <> wrote:
> Please give me your advice
> I was reading perltoot document, and I got stuck the following class
> global variable concept.
> HELP!!
>
> Why global variable should be accessed by hash like this? :
> $self->{"_CENSUS"}

That isn't a global variable. That is what they recommend using
*instead* of a global variable.

>
> Perltoot doc:
> Accessing Class Data
> It turns out that this is not really a good way to go about handling
> class data. A good scalable rule is that you must never reference
> class data directly from an object method. Otherwise you aren't
> building a scalable, inheritable class. The object must be the
> rendezvous point for all operations, especially from an object method.
> The globals (class data) would in some sense be in the "wrong" package
> in your derived classes. In Perl, methods execute in the context of
> the class they were defined in, not that of the object that triggered
> them. Therefore, namespace visibility of package globals in methods is
> unrelated to inheritance.(WHAT THE HECK HE IS TALKING ABOUT @.@??????)

Is there a particular part you are having trouble with, or is it the
entire paragraph? If the latter, are you familiar with OO outside the
Perl context?


>
> Got that? Maybe not. Ok, let's say that some other class
> "borrowed" (well, inherited) the DESTROY method as it was defined
> above. When those objects are destroyed, the original $Census variable
> will be altered, not the one in the new class's package namespace.
> Perhaps this is what you want, but probably it isn't.
> (WHAT THE HECK HE IS TALKING ABOUT @.@??????)

He is stalking about class inheritance, and the problems with using
global variables therein.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.