I just ran across the following bit of code in pudge's
journal on use Perl;
I just used "&&=" for the first time in real code. I hadn't
planned on it, but there it was:
my($cfg1, $cfg2, $VirtualUser) = @_;
$VirtualUser &&= getCurrentVirtualUser();
If the flag is true, then get the current value for the
virtualuser. Cool. It is weird when you have been using
perl for so long but use some feature for the first time.
So $VirtualUser changes it's meaning from 'do I
want the virtual user' to 'the virtual user is'.
This caught my eye because I recently wrote a procedure
in which a certain variable was first a string, then an
array reference, and then a hash reference. While in this
case the variable always signified the same thing (a header,
FWIW) and so is 'monosignant' the type changed not once
but twice ( polytypic? :), I thought perhaps I'd ask what
other people think of these things.
Are your variables invariably monosignant and monotypic? Why or why not?
On one hand I don't see why they should be (mono-*) if the flow
of the code suggests otherwise. On the other hand, I don't
expect my variables to change type and so I may get quite
confused when someone starts dereferencing what I was sure
was a plain string. On the gripping hand, if I pay attention I
should notice when said string becomes a hash ref, shouldn't
I?
I just can't decide whether this is a Good Thing(tm)
or not.
Scott
P.S. What do you think of 'polysignant'? Anyone got a
better word for what I mean?
Re: Polysignant variables
by Masem (Monsignor) on Aug 06, 2001 at 00:48 UTC
|
Well, from a coolness aspect, it's quite reasonable, however, I think it suffers weakly from a maintainence aspect, in that others that may not be ask skilled in perl will be confused.
OTOH, ||= is very cool, and maintainable, in using it to set default values when none are provided:
sub mysub($$;$) {
my ( $a, $b, $c ) = @_;
$c ||= 3; #c is 3 if not already defined
}
(Of course, this assumes that the value on the left is in some 'error' state if it's zero or undef.)
Not that &&= doesn't have it's usefulness while being maintainable, eg:
my $flag = 1;
foreach (@item) {
$flag &&= usable( $_ );
}
print $flag ? "All usable" : "not all usable";
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Polysignant variables
by John M. Dlugosz (Monsignor) on Aug 06, 2001 at 01:15 UTC
|
I've thought about references to different (incompatible signet, as opposed to conforming class) types with respect to overloading.
For example, a parameter can be a scalar meaning a string containing glob syntax, a qr meaning a Perl regular expression, or a sub ref, meaning a function that performs the match.
In Tk, an item can be a string representing the name of the member to trigger, a sub meaning call that, or an array ref, meaning call with arguments.
In those cases, good engineering would be to make them seem the same asap, or isolated. For example, in my matcher, I turn whatever it was into a sub, then deal only with that. In Tk, the "call this" function can be isolated, and it's just tramp data everywhere else.
I think reusing a local variable for different purposes throughout a body of code is bad coding.
—John | [reply] [Watch: Dir/Any] |
Re: Polysignant variables
by Zed_Lopez (Chaplain) on Aug 06, 2001 at 08:48 UTC
|
In general, I think it needlessly invites trouble in terms of
readability and maintainability to change types. It'd be pretty
easy for another programmer (and, of course, a few months
later that could be you) to see that some given scalar variable is a hashref, say, pass it as such... and waste time tracking down a puzzling error because it wasn't.
If one really thought some bit of code really called for it, commenting it'd probably be prudent.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Nomenclature
by John M. Dlugosz (Monsignor) on Aug 06, 2001 at 01:20 UTC
|
P.S. What do you think of 'polysignant'? Anyone got a better word for what I mean?
I think it sounds too much like poly-signet, so when I started reading I thought you specifically meant $foo vs @foo vs %foo, or refs pointing to different fundimental types at different times; not a variable being used for different things at different times.
For better ideas, see Roget on meaning/signification.
—John
| [reply] [Watch: Dir/Any] |
sigil
by da (Friar) on Aug 06, 2001 at 07:38 UTC
|
If the proper name for %, $, @, and * are sigils, I suspect polysigilant is a more proper term for what you describe, even though it's more of a mouthful than polysignet.
I suggest polytypic.
As to whether it's a good idea to do it, I really prefer my variables to be self-documenting all the way through the code, and it seems an unneccessary shortcut. If I did it, it probably would lead to confusion down the road.
Update: I'm not able to come up with the origin of the word sigil, but I first saw it in Damian Conway's Exegesis 2, and I know the term is used by gnat and japhy.
___
-DA
> perl -MPOSIX -e'$ENV{TZ}="US/Eastern";print ctime(10**9)'
Sat Sep 8 21:46:40 2001
| [reply] [Watch: Dir/Any] [d/l] |
|
Says [da]:
I'm not able to come up with the origin of the word sigil, but I first saw it in Damian Conway's Exegesis 2,
and I know the term is used by gnat and japhy.
The term 'sigil' to mean the funny character at the front of a Perl variable
was coined on 3 March 1999 by Philip Gwyn. I immediately posted
about it to p5p:
The source code actually uses the term `funny characters' to refer to
the $@%*& characters that select the variable type. This terminology
leaves a lot to be desired, but until now, I'd never heard a better
suggestion. They don't really have a good name. This has sometimes
been a problem for me when I've written documentation. The temptation
is to pretend that the funny character is part of the variable name,
which it isn't.
Philip Gwyn just used the word `sigil'. This struck me as a really
wonderful coinage that shouldn't be lost. The spelling of `sigil'
suggests `sign', which is good, and the word doesn't presently have
any other meaning in the Perl context, also good.
Glancing over man pages like `perldata' I can see a lot of places
where the explanations would become simpler or more accurate if the
word `sigil' were used.
Finally, according to the dictionary here, it means:
A sign or image considered magical.
Which is a really perfect description of it.
The term started catching on right away, and has gradually gained popularity.
| [reply] [Watch: Dir/Any] |
|
|
|
| [reply] [Watch: Dir/Any] |
|
Which of course to me sounds like polycygnant, or "having multiple swans." The pond by my house, for example, is polycygnant.
Of course, I suppose we could (if we're really trying to conjure up as much confusion as possible) overload THAT word as well: suppose a polycygnant variable is one that has multiple attributes; it's not totally out of line: attribute ~ albatross (worn around the variable's neck) ~ swan (another large white aquatic bird).
Of course, this babble is brought to you by the virus (in the microbial, not digital sense) I contracted yesterday, so take it FWIW.
Spud Zeppelin * spud@spudzeppelin.com
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
|