Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Polysignant variables

by scott (Chaplain)
on Aug 06, 2001 at 00:34 UTC ( [id://102340]=perlmeditation: print w/replies, xml ) Need Help??

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?

Replies are listed 'Best First'.
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

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

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.

      And if the concept is so complicated it needs a comment, why not introduce a properly named variable for each case and be done with it? :)

      The cost of a few more declared variables is low compared to the advantages of code clarity.

      /J

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

    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
        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.
        I've seen signet used reciently, in official circles. I remember looking it up, after reading something by Larry or Damian.

        Sigil is another word for signet. (http://www.dictionary.com/cgi-bin/dict.pl?term=sigil)

        —John

      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

        Since polycygnant with Perl, and the root sygnant isn't in general use, I don't think it's confusing since the "Perl context" should have you thinking of one vocabulary, and "Pond context" another. I can see them overlapping if you published an article on using Perl with your pond, though.

        Or, maybe polycygnant is what you call what happens when you have a program that requires both 1.x and 2.0 of cygwin.dll

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://102340]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (7)
As of 2024-03-28 11:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found