Jenda Krynicky wrote:
>
> Well at least it would not be using 'local' the way it does
> use it now. 'temporary' or something would make more sense.
> Local versus lexical variables are a big source of confusion :-(
Agreed. I'd vote for 'our local'.
/R
--
To unsubscribe, e-mail: [EMAIL PROTECT
>
> Not sure this is what you are after but ...
>
> *x = \15;
> print "\$x=$x\n";
> $x = 16; # => Modification of a read-only value attempted at ...
> print "\$x=$x\n";
>
> Jenda
You're a genius!
I'd love to understand further:
- why using a glob like that make
Dan Muey wrote:
>
> Howdy,
>
> I read in an earlier email that some people put _ in front of
> variables/function/etc to show that they are "important and should be
> handled by the program only" and it said that some "modules enforce this"
>
> I guess what I'm getting at is:
>
> If my module
Dan Muey wrote:
>
> I read in an earlier email that some people put _ in front
> of variables/function/etc to show that they are "important
> and should be handled by the program only" and it
> said that some "modules enforce this"
Hi Dan.
This is historical stuff, and ugly too. When there was no
It was Wednesday, August 13, 2003 when Dan Muey took the soap box, saying:
:
: If my module exports variables can I make it so they can't be changed?
Yes, but it's very complicated. You can see my example module
ex::constant::vars for a way to do it, but read all the documentation
first. :-)
From: "Rob Dixon" <[EMAIL PROTECTED]>
> David Wall wrote:
> > Rob Dixon wrote:
> >
> > > Lexical variables are another matter, as they don't belong to a
> > > given package but exist globally as long as there is a reference
> > > to them. In my opinion this is a bit of a hack, but access can be
> >
> > I guess what I'm getting at is:
> >
> > If my module exports variables can I make it so they can't
> be changed?
> >
> > IE
> >
> > use MyStuff qw($_joe $_mama); # now they should have $_joe
> > and $_mama exported from the module.
> >
> > print "$_joe $_mama\n"; # ok
> > my $joe = $_jo
David Wall wrote:
> Rob Dixon wrote:
>
> > Lexical variables are another matter, as they don't belong to a
> > given package but exist globally as long as there is a reference
> > to them. In my opinion this is a bit of a hack, but access can
> > be limited by creating data that is accessible only
> From: "Dan Muey" <[EMAIL PROTECTED]>
> > > Not sure this is what you are after but ...
> > >
> > > *x = \15;
> > > print "\$x=$x\n";
> > > $x = 16; # => Modification of a read-only value attempted at ...
> > > print "\$x=$x\n";
> > >
> > > Jenda
> >
> > You're a genius!
>
> No I'm n
> I guess what I'm getting at is:
>
> If my module exports variables can I make it so they can't be changed?
>
> IE
>
> use MyStuff qw($_joe $_mama); # now they should have $_joe
> and $_mama exported from the module.
>
> print "$_joe $_mama\n"; # ok
> my $joe = $_joe;# ok
>
--On Wednesday, August 13, 2003 9:16 PM +0100 Rob Dixon
<[EMAIL PROTECTED]> wrote:
Lexical variables are another matter, as they don't belong to a
given package but exist globally as long as there is a reference
to them. In my opinion this is a bit of a hack, but access can
be limited by creating
From: "Dan Muey" <[EMAIL PROTECTED]>
> If my module exports variables can I make it so they can't be changed?
Not sure this is what you are after but ...
*x = \15;
print "\$x=$x\n";
$x = 16; # => Modification of a read-only value attempted at ...
print "\$x=$x\n";
Thanks Jenda.
Jenda Krynicky wrote:
> > David Wall wrote:
> > > Rob Dixon wrote:
> > >
> > > > Lexical variables are another matter, as they don't belong to a
> > > > given package but exist globally as long as there is a reference
> > > > to them. In my opinion this is a bit of a hack, but access
> Dan Muey wrote:
> >
> > I read in an earlier email that some people put _ in front
> > of variables/function/etc to show that they are "important
> and should
> > be handled by the program only" and it said that some
> "modules enforce
> > this"
>
> Hi Dan.
>
> This is historical stuff, an
On Wed, 13 Aug 2003 14:13:28 -0500, "Dan Muey" <[EMAIL PROTECTED]> wrote:
>
> Don't have that one, I'll visit the library thoguh, Thanks
>
Closures are covered in a number of places, including:
perldoc perlref
http://perldoc.com/perl5.8.0/pod/
From: "Dan Muey" <[EMAIL PROTECTED]>
> > Not sure this is what you are after but ...
> >
> > *x = \15;
> > print "\$x=$x\n";
> > $x = 16; # => Modification of a read-only value attempted at ...
> > print "\$x=$x\n";
> >
> > Jenda
>
> You're a genius!
No I'm not. I saw this some
Howdy,
I read in an earlier email that some people put _ in front of variables/function/etc
to show that they are
"important and should be handled by the program only" and it said that some "modules
enforce this"
I guess what I'm getting at is:
If my module exports variables can I make it so
> It was Wednesday, August 13, 2003 when Dan Muey took the soap
> box, saying:
> :
> : If my module exports variables can I make it so they can't
> be changed?
>
> Yes, but it's very complicated. You can see my example
> module ex::constant::vars for a way to do it, but read all
> the docum
From: "Rob Dixon" <[EMAIL PROTECTED]>
> Jenda Krynicky wrote:
> > I don't think Perl4 is a valid reason to call anything in Perl5 an
> > afterthought. Unless you call the whole of Perl5 an afterthought.
>
> Not in that sense, but I don't believe Perl would have been designed
> that way from scratc
19 matches
Mail list logo
