A typeglob can be though of as a wildcard: *foo represents all of $foo, @foo, %foo etc. When you assign a reference to a typeglob, it replaces the slot in the typeglob corresponding to the the type of the reference, with that value; so

*foo = [ 1,2,3 ]
[download]

@foo = (1,2,3)
[download]

To get your code to compile, add an  our $z at the top.

Dave.

they will be removed completely in Perl6". So that might be a reason to avoid this particular type of magic,...

By that token, you should also avoid $array[ 1 ] = 2;, because that won't work in p6 either.

Nor will $hash{fred}=27;.

Nor will do { n++; } while $n < 10;.

Nor will print ( 'Hello, world!" );.

Nor will while( <DATA> ) { my @array = split'\t'' };.

Nor will keys %hash = 1000;.

Nor will for( my i=0; $i < @array; i++ ) {...};

Nor will $#array = 1_000_000;.

Read more... (357kB)

Nor will open FILE, '<', 'myfile' or die $!;.

But then again, local *array = \$arrayRef; won't be needed, because the syntax for

my @array;
push @array, $somevalue;
[download]

And

my $array = [];
push @array, $someValue;
[download]

Will be the same...or so it was at some point in time.

So, whilst P5 doesn't provide an alternative to the simplicity of

local *array = $aRef; 
push @array, $someValue;
[download]

it is a very useful construct to know.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

It's called a typeglob. To get your example to work you will need a use vars qw($z) or specify the full package of the variable:

use strict;
my $x=2;
*main::z=\$x;
print $main::z;
[download]

/J\

It's called a typeglob. To get your example to work you will need a use vars qw($z) or specify the full package of the variable:

or use our $z.

What is the meaning/purpose of code like

*z=\$x;
[download]

Is *var called the star sigil? Google doesn't seem to think so. Is this star stuff an artefact of an earlier version of perl?

If there are still reasons to use *var with modern perl, where can I learn more about it?

use vars '%SEPARATOR';
*SEPARATOR = \%SEPERATOR;
[download]

Rather than do a global search-and-replace on the source code, which is always dangerous

Run the tests before, make the change, and run the tests after. Fix what breaks. It's pretty easy.

Depends on the size of your code and how clean it is. IIRC, in this case the code was fairly old and poorly organized, with references to package globals spread across an unpleasantly large number of source files. I've never seen the code, but this is my strong impression. Though I am a strong supporter of good spelling among developers and people in general, I think in this case the risk-reward analysis didn't favor changing the existing code.

In the above example, I think it's more reasonable to get the official correct spelling, and have everyone learn a bit of spelling, than to use aliasing.

In the general case, you're assuming that a) there are tests to run, and, more importantly, b) that the tests have 100% coverage. While there may not be a lot of pity for the fool (apologies to Mr. T) in the first situation, the latter is much more realistic. Getting to 100% coverage is difficult, if not actually impossible once you've released a module and others may be using it beyond your ability to test/modify. Sometimes the alias is fixing what breaks. Then again, in this situation, search-and-replace doesn't really work, either.