class global variable?(from Perltoot document)

Discussion in 'Perl Misc' started by jh3an, Mar 11, 2008.

  1. jh3an

    jh3an Guest

    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, Mar 11, 2008
    #1
    1. Advertising

  2. 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/
    Joost Diepenmaat, Mar 11, 2008
    #2
    1. Advertising

  3. jh3an

    Guest

    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.
    , Mar 11, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bryan Parkoff
    Replies:
    2
    Views:
    6,480
  2. Replies:
    1
    Views:
    377
    Michael Ekstrand
    Aug 21, 2005
  3. Himanshu Garg
    Replies:
    1
    Views:
    152
    Himanshu Garg
    Sep 21, 2003
  4. perltoot bug?

    , Jul 11, 2006, in forum: Perl Misc
    Replies:
    0
    Views:
    99
  5. cmic

    overridden method in perltoot

    cmic, Aug 13, 2009, in forum: Perl Misc
    Replies:
    2
    Views:
    118
Loading...

Share This Page