Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.perl.misc > #4722 > unrolled thread

getting hash reference from a package

Back to article view | Back to comp.lang.perl.misc

Contents

  getting hash reference from a package Bill M <wpmccormick@just_about_everywhere.com> - 2012-03-13 11:28 -0500
    Re: getting hash reference from a package Bill M <wpmccormick@just_about_everywhere.com> - 2012-03-13 11:44 -0500
      Re: getting hash reference from a package tmcd@panix.com (Tim McDaniel) - 2012-03-13 17:56 +0000
        Re: getting hash reference from a package Bill M <wpmccormick@just_about_everywhere.com> - 2012-03-13 13:07 -0500
          Re: getting hash reference from a package Jack <goodcall1@hotmail.com> - 2012-03-14 01:57 -0600
            Re: getting hash reference from a package Martijn Lievaart <m@rtij.nl.invlalid> - 2012-03-14 12:06 +0100
              Re: getting hash reference from a package tmcd@panix.com (Tim McDaniel) - 2012-03-14 15:37 +0000
                Re: getting hash reference from a package Ben Morrow <ben@morrow.me.uk> - 2012-03-14 17:54 +0000
            Re: getting hash reference from a package Ben Morrow <ben@morrow.me.uk> - 2012-03-14 14:27 +0000
              Re: getting hash reference from a package Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-14 18:28 +0000
                Re: getting hash reference from a package Ben Morrow <ben@morrow.me.uk> - 2012-03-14 21:08 +0000
                  Re: getting hash reference from a package Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-14 21:23 +0000
            Re: getting hash reference from a package gbacon@hiwaay.net (Greg Bacon) - 2012-03-14 12:20 -0500
              Re: getting hash reference from a package Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-14 18:14 +0000
                Re: getting hash reference from a package gbacon@hiwaay.net (Greg Bacon) - 2012-03-16 12:11 -0500
                  Re: getting hash reference from a package Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-18 22:12 +0000
                    Re: getting hash reference from a package gbacon@hiwaay.net (Greg Bacon) - 2012-03-20 10:28 -0500
            Re: getting hash reference from a package Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-14 20:52 +0000

#4722 — getting hash reference from a package

What is the correct syntax for accessing a hash reference from a package?

For example:

Package MyPackage;

my $foo = {
	animals => ["cat", "dog", "fish"],
	people => ["fred", wilma" ]
};

1;

and then (this is what I THINK should work) ...

use MyPackage;

foreach my $animal (@{$MyPackage::$foo->{animals}}) {
	print $animal;
}


Thanks!!!

[toc] | [next] | [standalone]

#4723

Bill M wrote, On 3/13/2012 11:28 AM:
> What is the correct syntax for accessing a hash reference from a package?
>
> For example:
>
> Package MyPackage;
>
> my $foo = {
> animals => ["cat", "dog", "fish"],
> people => ["fred", wilma" ]
> };
>
> 1;
>
> and then (this is what I THINK should work) ...
>
> use MyPackage;
>
> foreach my $animal (@{$MyPackage::$foo->{animals}}) {
> print $animal;
> }
>
>
> Thanks!!!

Sorry, I meant this:

use MyPackage;

foreach my $animal (@{$MyPackage::foo->{animals}}) {
     print $animal;
}

[toc] | [prev] | [next] | [standalone]

#4724

In article <jjntgq$an4$1@dont-email.me>,
Bill M  <wpmccormick@just_about_everywhere.com> wrote:
>Bill M wrote, On 3/13/2012 11:28 AM:
>> What is the correct syntax for accessing a hash reference from a package?
>>
>> For example:
>>
>> package MyPackage;
>> my $foo = {
>> animals => ["cat", "dog", "fish"],
>> people => ["fred", "wilma" ]
>> };
>>
>> 1;

I added the missing double-quote before wilma and lowercased
"package".

"1;" usually comes at the end of a module file.  So I assume that
that's in its own file, named MyPackage.pm.

>use MyPackage;
Yeah, that requires a separate source file named MyPackage.pm or such.
>
>foreach my $animal (@{$MyPackage::foo->{animals}}) {
>     print $animal;
>}

Realize that "my" is lexical only.

(1) "my" does not create a package variable.  There is no
$MyPackage::foo variable in MyPackage.  When you refer to it in the
other file, it creates on that spot a variable set to undef.

(2) It's lexical only, so it exists only inside the file's scope.
It's not visible outside, so trying to refer to just "$foo" would get
you an error "Global symbol "$foo" requires explicit package name".

So replace "my" by "our" in MyPackage and it all works as you expect.

-- 
Tim McDaniel, tmcd@panix.com

[toc] | [prev] | [next] | [standalone]

#4725

Tim McDaniel wrote, On 3/13/2012 12:56 PM:
> In article<jjntgq$an4$1@dont-email.me>,
> Bill M<wpmccormick@just_about_everywhere.com>  wrote:
>> Bill M wrote, On 3/13/2012 11:28 AM:
>>> What is the correct syntax for accessing a hash reference from a package?
>>>
>>> For example:
>>>
>>> package MyPackage;
>>> my $foo = {
>>> animals =>  ["cat", "dog", "fish"],
>>> people =>  ["fred", "wilma" ]
>>> };
>>>
>>> 1;
>
> I added the missing double-quote before wilma and lowercased
> "package".
>
> "1;" usually comes at the end of a module file.  So I assume that
> that's in its own file, named MyPackage.pm.
>
>> use MyPackage;
> Yeah, that requires a separate source file named MyPackage.pm or such.
>>
>> foreach my $animal (@{$MyPackage::foo->{animals}}) {
>>      print $animal;
>> }
>
> Realize that "my" is lexical only.
>
> (1) "my" does not create a package variable.  There is no
> $MyPackage::foo variable in MyPackage.  When you refer to it in the
> other file, it creates on that spot a variable set to undef.
>
> (2) It's lexical only, so it exists only inside the file's scope.
> It's not visible outside, so trying to refer to just "$foo" would get
> you an error "Global symbol "$foo" requires explicit package name".
>
> So replace "my" by "our" in MyPackage and it all works as you expect.
>
Thanks, just figured it out then saw your answer as I was about to reply 
to myself.

[toc] | [prev] | [next] | [standalone]

#4727

On 13/03/2012 12:07 PM, Bill M wrote:
> Tim McDaniel wrote, On 3/13/2012 12:56 PM:
>> In article<jjntgq$an4$1@dont-email.me>,
>> Bill M<wpmccormick@just_about_everywhere.com> wrote:
>>> Bill M wrote, On 3/13/2012 11:28 AM:
>>>> What is the correct syntax for accessing a hash reference from a
>>>> package?
>>>>
>>>> For example:
>>>>
>>>> package MyPackage;
>>>> my $foo = {
>>>> animals => ["cat", "dog", "fish"],
>>>> people => ["fred", "wilma" ]
>>>> };
>>>>
>>>> 1;
>>
>> I added the missing double-quote before wilma and lowercased
>> "package".
>>
>> "1;" usually comes at the end of a module file. So I assume that
>> that's in its own file, named MyPackage.pm.
>>
>>> use MyPackage;
>> Yeah, that requires a separate source file named MyPackage.pm or such.
>>>
>>> foreach my $animal (@{$MyPackage::foo->{animals}}) {
>>> print $animal;
>>> }
>>
>> Realize that "my" is lexical only.
>>
>> (1) "my" does not create a package variable. There is no
>> $MyPackage::foo variable in MyPackage. When you refer to it in the
>> other file, it creates on that spot a variable set to undef.
>>
>> (2) It's lexical only, so it exists only inside the file's scope.
>> It's not visible outside, so trying to refer to just "$foo" would get
>> you an error "Global symbol "$foo" requires explicit package name".
>>
>> So replace "my" by "our" in MyPackage and it all works as you expect.
>>
> Thanks, just figured it out then saw your answer as I was about to reply
> to myself.

Question: Is it proper to access a package variable directly? Would it 
not be better to provide a method to retrieve the reference?

Jack

[toc] | [prev] | [next] | [standalone]

#4728

On Wed, 14 Mar 2012 01:57:07 -0600, Jack wrote:

> Question: Is it proper to access a package variable directly? Would it
> not be better to provide a method to retrieve the reference?

Even better, provide a getter and a setter (or combine them).

Something like:

my $global_debug_flag;

sub debugging {
	$global_debug_flag = $_[0] if defined $_[0];
	return $global_debug_flag;
}

M4

[toc] | [prev] | [next] | [standalone]

#4730

In article <ina639-3qd.ln1@news.rtij.nl>,
Martijn Lievaart  <m@rtij.nl.invlalid> wrote:
>On Wed, 14 Mar 2012 01:57:07 -0600, Jack wrote:
>
>> Question: Is it proper to access a package variable directly? Would
>> it not be better to provide a method to retrieve the reference?
>
>Even better, provide a getter and a setter (or combine them).

That's certainly the fashion in object-oriented code.  I may be
showing my ignorance, but I'm afraid I don't see the benefit in doing
that for a single uncomplicated global variable.  An object with
complicated semantics, or semantics that must be constrained and
checked for validity, of course -- that's one of the points of
object-oriented code, and it's a very useful technique.  But a simple
count, say, or a string that's unrelated to anything else?  Why not
require getters and setters for that are visible for more than 50
lines, say, or for all variables?

-- 
Tim McDaniel, tmcd@panix.com

[toc] | [prev] | [next] | [standalone]

#4733

Quoth tmcd@panix.com:
> 
> That's certainly the fashion in object-oriented code.

Good practice in OO code would be to make something like that a method
on the object. That way if you choose to make the debugging level (or
whatever it is) per-object later on, you can.

Wrapping a simple variable like that in a plain function, or in a class
method, I agree seems pointless.

> Why not require getters and setters for [?variables] that are visible
> for more than 50 lines, say, or for all variables?

If you've got a (not file-scoped) lexical that's visible for more than
50 lines you need to refactor.

Ben

[toc] | [prev] | [next] | [standalone]

#4729

Quoth Jack <goodcall1@hotmail.com>:
> 
> Question: Is it proper to access a package variable directly? Would it 
> not be better to provide a method to retrieve the reference?

If the value is truly global then there's very little point wrapping the
variable in a sub. A sub like

    sub my_global { \$Foo }

or even

    sub set_my_global { $Foo = $_[0] }

isn't hiding anything: no matter what you do later, there can still only
be one value of $Foo across all users of your module, so it might as
well be a package global.

Ben

[toc] | [prev] | [next] | [standalone]

#4736

Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Jack <goodcall1@hotmail.com>:
>> 
>> Question: Is it proper to access a package variable directly? Would it 
>> not be better to provide a method to retrieve the reference?
>
> If the value is truly global then there's very little point wrapping the
> variable in a sub. A sub like
>
>     sub my_global { \$Foo }
>
> or even
>
>     sub set_my_global { $Foo = $_[0] }
>
> isn't hiding anything:

There might actually be an advantage in doing so: It helps with
debugging if all accesses to some object also go through a certain
piece of code, because this provides a location where debugging
statements or debugger breakpoints can be added.

[toc] | [prev] | [next] | [standalone]

#4740

Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Jack <goodcall1@hotmail.com>:
> >> 
> >> Question: Is it proper to access a package variable directly? Would it 
> >> not be better to provide a method to retrieve the reference?
> >
> > If the value is truly global then there's very little point wrapping the
> > variable in a sub. A sub like
> >
> >     sub my_global { \$Foo }
> >
> > or even
> >
> >     sub set_my_global { $Foo = $_[0] }
> >
> > isn't hiding anything:
> 
> There might actually be an advantage in doing so: It helps with
> debugging if all accesses to some object also go through a certain
> piece of code, because this provides a location where debugging
> statements or debugger breakpoints can be added.

perldebug:
|   w expr      Add a global watch-expression. Whenever a watched global
|               changes the debugger will stop and display the old and new
|               values.

Ben

[toc] | [prev] | [next] | [standalone]

#4741

Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Jack <goodcall1@hotmail.com>:
>> >> 
>> >> Question: Is it proper to access a package variable directly? Would it 
>> >> not be better to provide a method to retrieve the reference?
>> >
>> > If the value is truly global then there's very little point wrapping the
>> > variable in a sub. A sub like
>> >
>> >     sub my_global { \$Foo }
>> >
>> > or even
>> >
>> >     sub set_my_global { $Foo = $_[0] }
>> >
>> > isn't hiding anything:
>> 
>> There might actually be an advantage in doing so: It helps with
>> debugging if all accesses to some object also go through a certain
>> piece of code, because this provides a location where debugging
>> statements or debugger breakpoints can be added.
>
> perldebug:
> |   w expr      Add a global watch-expression. Whenever a watched global
> |               changes the debugger will stop and display the old and new
> |               values.

This is notoriously unreliable for 'non-managed code' (not applicable
to perl) and only the lesser half of the possible advantage. Also, I
wrote 'their might' for a reason: This depends on what debugging tools
can be used in a given situation and what their capabilities are.

[toc] | [prev] | [next] | [standalone]

#4732

Jack wrote:

: Question: Is it proper to access a package variable directly? Would it
: not be better to provide a method to retrieve the reference?

As a rule of thumb, pass parameters to subs and methods rather than
communicating through global variables. A singleton is a global variable
dressed in fancy clothes, so avoid those too.

Be more specific about what you want your code to do. Then we can give
you specific, helpful advice for your situation rather than vague
generalities.

Greg
-- 
I know different people will have different lists. That's good.
I'll make a list of lists. It'd be nice if I had a good language
for manipulating complex data structures. Oh, wait...
    -- Chip Salzenberg in perl6-internals

[toc] | [prev] | [next] | [standalone]

#4734

gbacon@hiwaay.net (Greg Bacon) writes:
> Jack wrote:
> : Question: Is it proper to access a package variable directly? Would it
> : not be better to provide a method to retrieve the reference?
>
> As a rule of thumb, pass parameters to subs and methods rather than
> communicating through global variables. A singleton is a global variable
> dressed in fancy clothes, so avoid those too.

A singleton is the Java programmer's workaround for the fact that
Java requires everything to be an instance of some class, that is,
a general blueprint for construction objects of certain kinds, but
that many real-world problems are easier dealt with by systems
constructed of stateful modules ('subsystems') providing some kind of
identifiable, useful functionality for solving a part of the original
problem (that's similar to complex real machines which are also
composed of cooperating 'sub-machines' dealing with 'subtasks' of the
problem supposed to be solved).

Apart from that, an object instance is a set of variables shared by
some set of cooperating subroutines and this is nothing but 'a global
variable dressed in fancy clothes'. Some people are convinced that
complex objects whose state changes over time are Evil[tm] and should
be avoided. Except when the result can be eaten, I presume ...

[toc] | [prev] | [next] | [standalone]

#4770

Rainer Weikusat wrote

: A singleton is the Java programmer's workaround for the fact that
: Java requires everything to be an instance of some class, that is,
: a general blueprint for construction objects of certain kinds, but
: that many real-world problems are easier dealt with by systems
: constructed of stateful modules ('subsystems') providing some kind of
: identifiable, useful functionality for solving a part of the original
: problem (that's similar to complex real machines which are also
: composed of cooperating 'sub-machines' dealing with 'subtasks' of the
: problem supposed to be solved). [...]

The singleton pattern[1] isn't specific to Java even though denizens
of that language do tend to fetishize it. Java doesn't require
everything to be an instance of a class, the counterexample aside
from basic types being static methods. Even so, say we have the
module-qua-class

  public class MyModule {
    static int calls_ = 0;

    public static void SayHi() {
      ++calls_;
      System.out.println("Hello!");
    }

    public static void SayBye() {
      ++calls_;
      System.out.println("Good-bye!");
    }

    public static int Calls() {
      return calls_;
    }
  }

MyModule fits your description above, but it is not a singleton.
The name of the pattern derives from the constraint that a system
may have at most a single instance of such a class. You might claim
that a bag of static methods meets the definition in its vacuous
sense, but such usage robs the term of its meaning.

Rather than imposing the single-instance constraint, creating a
singleton as a shortcut to bypass threading the instance through
the call graph is a frustratingly common practice. It's a global
variable dressed up in fancy clothes but comes with all the same
headaches.

[1]: http://en.wikipedia.org/wiki/Singleton_pattern

Greg
-- 
 ... the several states who formed [the Constitution], being sovereign and
independent, have the unquestionable right to judge of its infraction; and
that a nullification, by those sovereignties, of all unauthorized acts done
under colour of that instrument, is the rightful remedy ... -- Ky. Resolution

[toc] | [prev] | [next] | [standalone]

#4793

gbacon@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat wrote
> : A singleton is the Java programmer's workaround for the fact that
> : Java requires everything to be an instance of some class, that is,
> : a general blueprint for construction objects of certain kinds, but
> : that many real-world problems are easier dealt with by systems
> : constructed of stateful modules ('subsystems') providing some kind of
> : identifiable, useful functionality for solving a part of the original
> : problem (that's similar to complex real machines which are also
> : composed of cooperating 'sub-machines' dealing with 'subtasks' of the
> : problem supposed to be solved). [...]
>
> The singleton pattern[1] isn't specific to Java even though denizens
> of that language do tend to fetishize it. Java doesn't require
> everything to be an instance of a class, the counterexample aside
> from basic types being static methods. Even so, say we have the
> module-qua-class
>
>   public class MyModule {
>     static int calls_ = 0;
>
>     public static void SayHi() {
>       ++calls_;
>       System.out.println("Hello!");
>     }
>
>     public static void SayBye() {
>       ++calls_;
>       System.out.println("Good-bye!");
>     }
>
>     public static int Calls() {
>       return calls_;
>     }
>   }
>
> MyModule fits your description above, but it is not a singleton.
> The name of the pattern derives from the constraint that a system
> may have at most a single instance of such a class. You might claim
> that a bag of static methods meets the definition in its vacuous
> sense, but such usage robs the term of its meaning.

Since there's no class instance in the example above, it obviously
doesn't make sense to call it 'a singleton'. OTOH, both serve the
same purpose: Express the concept of 'a subsystem', that is, some set
of state variables shared by some set of 'public' interface routines
intended to solve a subproblem of the problem the program containing
this code is supposed to solve, in Java. For the purpose of this
discussion, ie, the 'global variable dressed in fancy clothes' issue,
both have the same properties and there's actually nothing wrong with
that: A subsystem is isomorph to a single instance of some class
(that's exploited by the so-called 'singleton pattern') and this
implies that any single object is nothing but 'a fancily dressed
global variable'. 

> Rather than imposing the single-instance constraint, creating a
> singleton as a shortcut to bypass threading the instance through
> the call graph is a frustratingly common practice.

Hmm ... what is this supposed to mean?

[toc] | [prev] | [next] | [standalone]

#4821

Rainer Weikusat wrote:

: Since there's no class instance in the example above, it obviously
: doesn't make sense to call it 'a singleton'. OTOH, both serve the
: same purpose: Express the concept of 'a subsystem', that is, some set
: of state variables shared by some set of 'public' interface routines
: intended to solve a subproblem of the problem the program containing
: this code is supposed to solve, in Java. For the purpose of this
: discussion, ie, the 'global variable dressed in fancy clothes' issue,
: both have the same properties and there's actually nothing wrong with
: that: A subsystem is isomorph to a single instance of some class
: (that's exploited by the so-called 'singleton pattern') and this
: implies that any single object is nothing but 'a fancily dressed
: global variable'. 

I'm not shooting from the hip here. A well-known point of anguish
with singletons is they make testing difficult and sometimes
excruciating. Substitution and mocking are painful. As with global
variables, interaction with singletons is not expressed in the
interface, so the poor developer has to remember that particular
implementation detail.

These considerations apply to bags of static methods too because the
approach also comes with these severe drawbacks.

: Greg Bacon wrote
:
: > Rather than imposing the single-instance constraint, creating a
: > singleton as a shortcut to bypass threading the instance through
: > the call graph is a frustratingly common practice.
:
: Hmm ... what is this supposed to mean?

The singleton pattern is supposed to enforce the constraint that a
given system will never have more than a single instance.

As for actual usage in the wild, I wouldn't be shocked at all
to learn that 4 out of 5 singletons have no single-instance
requirement. Without this constraint, the singleton pattern as
commonly implemented offers the specious benefit of providing access
to the "singleton" instance without having to go to all the trouble
of, you know, passing the "singleton" instance to client methods.

In other words, it tends to be a sign of sloppy programming, sloppy
for the same reasons and because of the same drawbacks as global
variables.

Greg
-- 
"Those who deliberately sign their names to deception will be punished,"
[President Bush] said, leaving out that this is precisely what happens
every time he signs a budget or a law, or Congress votes.
    -- Lew Rockwell

[toc] | [prev] | [next] | [standalone]

#4739

Jack <goodcall1@hotmail.com> writes:

[...]


> Question: Is it proper to access a package variable directly? Would it
> not be better to provide a method to retrieve the reference?

What do you mean by 'proper'? Eg, the typical example for something
where anything but enabling direct access to 'a package variable'
makes little sense would be some kind of 'debugging level' variable
which can be used to control the amount of diagnostics a program will
print: That's typically modified in one or two location (the code
which deal with command-line arguments and something like a signal
handler which can be used to change the value for a running program)
and read-only referenced from everywhere else in the code. This really
depends on the purpose of the variable.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.perl.misc

csiph-web