#1
  1. No Profile Picture
    Contributing User
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2003
    Posts
    3,617
    Rep Power
    595

    Syntax I've Not Seen before


    I've not seen the following syntax before. Can someone explain what it means?
    Code:
    my ($MLInfo1) = 'eifadm';
    my ($MLInfo2) = 'Dortches';
    &MailerList::SetAccount(-userid => $::MLInfo1, -password => $::MLInfo2);
    I don't know the significance of '&' in front of MailerList or '$::' in front of MLInfo. TIA.
    There are 10 kinds of people in the world. Those that understand binary and those that don't.
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2012
    Posts
    71
    Rep Power
    3
    Originally Posted by gw1500se
    I've not seen the following syntax before. Can someone explain what it means?
    Code:
    my ($MLInfo1) = 'eifadm';
    my ($MLInfo2) = 'Dortches';
    &MailerList::SetAccount(-userid => $::MLInfo1, -password => $::MLInfo2);
    I don't know the significance of '&' in front of MailerList or '$::' in front of MLInfo. TIA.
    The '&' is the sigil for sub-routines and the '$::' tranlates to the sigil for a scalar in the main package(:: means main package..I think).
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,968
    Rep Power
    1225
    Like vars, subroutines have a sigil. As you (should) know, $ is the sigil for a scalar, @ is the sigil for an array, % is the sigil for a hash, and & is the sigil for subs.

    Subs differ from the vars with respect to the sigil. Its usage is optional in most cases and has side affects when used. The vast majority of the time, you don't need or want those side affects, so the & sigil is generally left off unless it's actually needed, such as when creating a reference to the sub.

    Vars can be referred to by their fully qualified package name. An example, which you've probably seen/used, is in the connect statement of the DBI module.
    Code:
    my $dbh = DBI->connect($dsn, 'user', pass) or die $DBI::errstr;
    $ is the sigil denoting a scalar, DBI is the package name and errstr is the varname.

    When you see $::varname the package is main, so that var is normally written as $varname.

    The fact that the author of that code snippet is using these "features" tells me that the author is inexperienced.
    Last edited by FishMonger; November 6th, 2012 at 11:12 AM.
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2003
    Posts
    3,617
    Rep Power
    595
    Thanks for the replies. So I think you are telling me the '$::' can be changed to the usual '$'. I don't know who created this script but I am tasked with fixing it. I kind of thought those references were at best unnecessary. I think the '&' is unnecessary as well. What prompted me to ask this question is that I get a warning:

    Name "main::MLInfo1" used only once: possible typo at ...

    I was not sure what I was getting into. I have done a lot of perl programming but I am not an expert either.
    There are 10 kinds of people in the world. Those that understand binary and those that don't.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,968
    Rep Power
    1225
    I would not have expected that warning, but it appears that when using $:: the var needs to be a package global, not a lexical var.

    So, you could fix it by declaring the var with 'our' instead of 'my', which is NOT the best solution.

    So I think you are telling me the '$::' can be changed to the usual '$'.
    Yes, that is what I'm telling you.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2003
    Posts
    3,617
    Rep Power
    595
    I haven't dealt with packages so I am on new ground here. However, I see that the MailerList package contains similar code:
    Code:
    my ($MLInfo1) = 'eifadm';
    my ($MLInfo2) = 'Dortches';
    
    SetAccount(-userid => $MLInfo1, -password => $MLInfo2);
    I don't understand the logic between the script I'm working on and the package. So what should I be looking at to fix this?
    There are 10 kinds of people in the world. Those that understand binary and those that don't.
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,968
    Rep Power
    1225
    I don't see anything in this snippet that needs fixing.

    Are you receiving any error/warning?
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2003
    Posts
    3,617
    Rep Power
    595
    Not from the package. What I'm not understanding is why those values are being set in the package (presumably when it is loaded by 'require') and set the same again in the script where I get the warnings. It seems to me that they are redundant in the script and removing them also gets rid of the warnings. Am I missing something about packages when they are loaded?
    There are 10 kinds of people in the world. Those that understand binary and those that don't.
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,968
    Rep Power
    1225
    Just because they are using the same var name doesn't mean that they are the same vars, in fact they are not. Lexical vars are limited to the scope of their enclosing block or to the file if they are not in a block. Since these vars were defined as lexicals, not globals, in each file, then at most their scope will be limited to the file in which they are declared.

    If we're talking about a library file loaded with require as opposed to a package, which is a separate namespace, then you would be receiving a different warning/error.
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2003
    Posts
    3,617
    Rep Power
    595
    What I am referring to are the variables passed to the method SetAccount. They are set with the same values in the package and script. They are used nowhere else. Since in neither case are they used for any other purpose, I don't see how the code is not redundant regardless of scoping.

    We are indeed talking about loading the file with require. I refer to one as a package because it has a package statement in it and to distinguish it from the script I am trying to debug. I know it is technically not a package because of how it is loaded but it makes references less confusing in this thread. As I indicated earlier there is no warning referencing the package, only the redundant (IMO) statements in the script.
    There are 10 kinds of people in the world. Those that understand binary and those that don't.
  20. #11
  21. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,968
    Rep Power
    1225
    It's not the method of loading (i.e., use or require) that determines if it's a package and hence a new namespace. It's the fact that it uses a package statement.

    See perldoc -f package

    The vars used in the package have no correlation to the vars used in the script even though they are named the same.
  22. #12
  23. No Profile Picture
    Contributing User
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2003
    Posts
    3,617
    Rep Power
    595
    Again, I am not talking about the var names, I am talking about their VALUES being passed to the method.
    There are 10 kinds of people in the world. Those that understand binary and those that don't.
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Apr 2009
    Posts
    1,968
    Rep Power
    1225
    Without seeing the full code, I can't say if there is any real problem with it, but hard coding usernames and passwords in a module/package is a sign of poor design.
  26. #14
  27. No Profile Picture
    Contributing User
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2003
    Posts
    3,617
    Rep Power
    595
    No disagreement there.
    There are 10 kinds of people in the world. Those that understand binary and those that don't.

IMN logo majestic logo threadwatch logo seochat tools logo