in reply to Global Functions? sent and returned values
I'm not entirely clear what you're trying to do - there are approximately 2 different call styles in perl. And they all have their nuances, none of which are necessarily completely obvious to the casual newbie.
This is where you call a function directly. There is no runtime lookup of where a function is, which gains some speed, at the expense of flexibility (which, to be honest, is not wanted most of the time anyway).
There are two variations here. The first variation is what you're used to: some_func(). The nuance? That some_func may be declared in the same file as where you're calling it, or it may be exported there from another package (or namespace). Note that even if it's exported, Perl only looks in the current namespace or package to find it - the act of exporting merely makes a copy of the function from the originating namespace/package in to your namespace/package. No extra parameters are used:
Advantages: no extra parameters, very simple, you can actually get the same function name from a new module if you decide to move things around, and not change anything but the use statement. Disadvantages: you may not always be acutely aware of where functions are coming from (which is why some would encourage you to make your imports explicit in your use statements).my $returned = some_func($sent); # ... sub some_func { my $received = shift; # ... $value; }
The second variation, which I think is what you're looking for, is fully-qualified naming. It's the same as the previous one, but is longer-winded.
Advantages: You can call functions that aren't even exported. Disadvantages: if the function gets moved to a new module, you need to change all the calls. Also, if it's not being exported, you probably aren't supposed to call it anyway - caveat emptor!my $returned = Foo::Bar::some_func($sent); # in Foo::Bar: sub some_func { my $received = shift; #... $value; }
Here we tell Perl where to start looking. It may decide to look elsewhere after that if it can't find the function you're asking for. This can chew up a few cycles just resolving the function call. You can distinguish this style from the previous one by the fact that the arrow notation is used.
The first variation is class-indirect. This is used primarily for constructors and by File::Spec. If you don't know why File::Spec does it this way, you probably don't want to do it yourself - it's somewhat advanced, IMO. And I've never needed to do it, either, so it's a good bet you probably don't either.
Advantages: being able to crawl up the @ISA inheritence tree to find a method. Disadvantages: can be quite confusing until you really understand it.my $returned = Foo::Bar->some_func($sent); # in Foo::Bar (or any package that Foo::Bar derives from) sub some_func { my $class_name = shift; # will be Foo::Bar, even if we aren't in t +hat package right now my $received = shift; # ... $value }
The other variation is object-indirect. This is where you have an object created via a constructor, and then call methods on it. This is a very popular style as it is what allows us to call perl "Object Oriented" (as much as, say, C++ or Java are, but not as much as other languages such as Smalltalk). Perl starts with the package of the object given, and walks up the @ISA inheritance tree the same as before if it can't find the method in the starting package.
Advantages: see OOP (Object Oriented Programming). Disadvantages: Same ;-)my $returend = $obj->some_func($sent); # in the package that $obj is blessed into, or any package it is der +ived from sub some_func { my $self = shift; my $received = shift; #... $value; }
|
|---|