How can I turn this two statement snippet into a single statement?
my $handle = &get_handle('parameter');
$handle->do_stuff;
Something like {&get_handle('parameter')}->do_stuff;, but what would be the correct syntax?
There's no requirement for a variable to be used on the left-hand side of the ->. It can be any expression, so you can simply use
get_handle('parameter')->do_stuff
It's actually quite common. For example,
$self->log->warn("foo"); # "log" returns the Log object.
$self->response->redirect($url); # "response" returns a Response object.
$self->config->{setting}; # "config"s return a hash.
get_handle('parameter')->do_stuff
Related: When should I use the & to call a Perl subroutine?
Related
I am new to Perl and reading about references.
I can not understand how doe one know if the variable he work on is a reference.
For instance if I understand correctly, this:
$b = $a could be assigning scalars or references. How do we know which is it?
In C or C++ we would know via the function signature (*a or &a of **a). But in Perl there is no signature of parameters.
So how do we know in code what is a reference and what is not? Or if it is a reference to scalar or array or hash or another reference?
Perl has a ref that you can use for that:
Returns a non-empty string if EXPR is a reference, the empty string otherwise. [...]
The string returned (if non-empty) will tell you the type of object the reference references.
You're asking the wrong question.
While there is a function called ref and another called reftype, these are not functions you should ever need to use.
It's bad to check the type of variables, because there's no way to effectively know without actually using it as intended due to overloading and magic.
For example, say you designed a function that accepts a reference or a string. That would be a bad design because an object that overloads stringification is both.
A good interface would use context to differentiate the arguments. For example, it could differentiate based on the number of arguments,
foo($point_obj)
-vs-
foo(x => $x, y => $y)
based on the value of other arguments,
foo(fh => $fh)
-vs-
foo(str => $file_contents)
or based on the choice of function called
foo_from_fh($fh)
-vs-
foo($file_contents)
So the answer is: You know it's a reference because your documentation instructs the caller of your function to pass a reference. If you got passed something other than a reference and it's used as a reference, the caller will get a strict error for their error.
The ref function is what you're looking for. Documentation is available at http://perldoc.perl.org/functions/ref.html
ref EXPR
Returns a non-empty string if EXPR is a reference, the empty string otherwise. If EXPR is
not specified, $_ will be used. The value returned depends on the type of thing the
reference is a reference to...
I have a perl script and it works on perl version 5.8.8 but 5.14 got that error: Odd number of elements in anonymous hash at
Here is my code:
$session->begin_privileged({ $_enable_password })
Previously it was like this:
$session->begin_privileged( $_enable_password )
And at this time I get this error:
Single parameters to new() must be a HASH ref data
I have similar typed lines like above and I get same Single parameters error on each.
I googled it but could not find a regular solution.
If $session is an instance of Net::Appliance::Session then your call should look like this:
$session->begin_privileged({ password => $_enable_password });
But I am still not sure that $_enable_password isn't a hash reference in the first place, in which case you should pass it as a single parameter without enclosing braces. It is a much more likely explanation that $_enable_password isn't being set up correctly than that Perl v14 has stopped it working.
unless defined(&dl_load_file);
The above looks ambiguous to me but actually works .
How does Perl know whether or not to call dl_load_file here?
It's just a special case in Perl's syntax. If you have either defined(&identifier) or defined &identifier, it checks for the existence of a subroutine named identifier without calling it, even though &identifier would normally call the subroutine.
defined &identifier(), on the other hand, does call the subroutine and then test its return value. The parens after identifier make it a function call.
I think there is not a call - is just a check to see if that function is defined or not
Perl interpreter knows this with the help of Symbol Tables
Can anyone give an example of how a string can be returned from a call using Win32::API() function? I need to return a string and print using $val. Please give an example if the same can be handled using pointer as return type.
use Win32::API;
my $res = new Win32::API('abc.dll','MyFun','_argument type list_','_Return type list_')or die $^E;
my $val= $res->Call();
print ($val);
The documentation for Win32::API's Call() method suggests that you must pass Call() a scalar which will be used as a buffer to store the returned value; Call() itself will return whether the call succeeded or not.
Example:
my $return_buffer = " " x 80;
if ($res->Call(80, $return_buffer)) {
print "OK, the API call returned '$return_buffer'\n";
} else {
print "The API call failed for some reason.\n";
}
EDIT: quoting from the docs for completeness:
The two parameters needed here are the length of the buffer that will hold the returned temporary path, and a pointer to the buffer itself. For numerical parameters, you can use either a constant expression or a variable, while for pointers you must use a variable name (no Perl references, just a plain variable name). Also note that memory must be allocated before calling the function, just like in C. For example, to pass a buffer of 80 characters to GetTempPath(), it must be initialized before with:
$lpBuffer = " " x 80;
This allocates a string of 80 characters. If you don't do so, you'll probably get Runtime exception errors, and generally nothing will work. The call should therefore include:
$lpBuffer = " " x 80;
$GetTempPath->Call(80, $lpBuffer);
And the result will be stored in the $lpBuffer variable. Note that you don't need to pass a reference to the variable (eg. you don't need \$lpBuffer), even if its value will be set by the function.
I don't see any obvious problem with the way you are doing this. The Win32::API module is capable of receiving a char * from a DLL function and transforming it into a Perl scalar. This code, for example, does what I expect:
use Win32::API;
$GetCommandLine = Win32::API->new('kernel32',
'LPTSTR GetCommandLine()');
$val = $GetCommandLine->Call();
print "The command line of this program is: $val\n";
which is to print
The command line of this program is: C:\strawberry\perl\bin\perl.exe win32-api-string.pl
The obvious things are to check the return values as well as $! and $^E from every step of your code and that abc.dll is in your program's $PATH. You might want to drop the .dll from the function call (just say Win32::API->new('abc', ...) ) -- none of the examples ever explicitly include the .dll extension, and perhaps the module assumes that you won't use it (and will try to load a library from abc.dll.dll instead).
You also might want to try using the Win32::API constructor from a prototype, as I have done in my example. I find that this gives me fewer headaches setting the right argument and return types properly (but occasionally more headaches trying to shoe horn some object type into the list of types that Win32::API supports out of the box). (The parameter list style constructor is now deprecated anyway, according to the v0.59 docs).
How can I find which object type I am dealing with in Perl? I tried using perl -d to enter the debugger, but I'm not sure what to do then. Likewise I'd like a way to easily see which methods are available for each object, how can that be done?
The standard way for telling what type of object you have is either ref or Scalar::Util::blessed. If you know the object is blessed, then they return the same information.
my $class1 = blessed( $obj );
my $class2 = ref $obj;
But ref will also return 'HASH' for unblessed hashes, while blessed refuses to play that game.
As for a list of methods, for the blessed pointer style of perl object, it's easy enough to code one up yourself. The code below works fairly well for me. It returns the names of functions (those taking the "CODE slot" of the given name) mapped to the package which defines them.
sub class_methods {
use Class::ISA;
my $obj = shift;
return unless ref( $obj );
my %meth_names;
foreach my $anc ( Class::ISA::self_and_super_path( ref $obj ), 'UNIVERSAL' ) {
my $stash = \%{"$anc\::"};
my #funcs
= grep { m/^[_\p{Alpha}]/ # begins with _ or alpha
&& !exists $meth_names{$_} # no clobbering
&& defined *{$stash->{$_}}{CODE} # has a filled CODE slot
} keys %$stash
;
# assign to the "hash slice", keyed by all the entries in #funcs
# the value of $anc repeated as many times as elements in #funcs.
#meth_names{#funcs} = ( $anc ) x #funcs;
}
return %meth_names;
}
This will work for reasonably complex objects as well, but if the owning package contains a lot of generated code, it's not going to be that helpful to know which package the generators stuck the code pointer in. It's going to mean more to find what package generated the code.
This being the case, you might get the code out of running your code, including Data::Dumper and setting $Data::Dumper::Deparse to 1, like so: ( local $Data::Dumper::Deparse = 1;) and then dumping the code pointer, like so: say Dumper( $code_ref );
It WON'T work for valid methods that have yet to be created by any AUTOLOAD methods. If you see those in the list, the object might do more, but what all it does, you don't know.
The "base class" UNIVERSAL is included, because that class contains behavior usable by the object.
Good luck.
The blessed function from Scalar::Util will tell you the package name of any blessed reference (an object.)
To find out what methods are available, consult the documentation for that package. Alternatively, you can use something like Class::MOP::Class to instantiate a metaclass and get introspective information about the methods it contains.
Just for completeness, here's a very short intro to the debugger.
perl -d your_program
starts it under the bugger. You'll get control at the first executable line (use statements and the like have already executed at this point).
's' will step to the next line. Once you've entered an 's', you can simply press return to repeat it. 's' will step down into functions/subroutines/methods. Either keep stepping till you return or enter the 'r' command to execute the rest of the function and return to right after the call.
If you want to step 'over' subroutines - that is, execute them and return without having to step in and return, use 'n. The carriage return after the first 'n' also keeps doing 'n' for you.
If you know the line where you want to stop, use the 'b' command - b linenumber - to set a breakpoint, then 'c' to continue till you reach it. Note that every time you 'c' and come back to the breakpoint you will stop again. Use 'B linenumber' to turn the breakpoint back off.
So let's assume you've gotten to something like this:
my $obj = complex_function_returning_unknown_thing;
The debugger's just shown you this line, which says "I have not executed this yet, but it is what I will do next." Enter 'n' to execute the subroutine, then use the 'x' command to look at the object: 'x $obj'. If it's big, you can say '|x $obj' which runs the output through a pager. To see what methods the object has, use 'm $obj'.
There's a lot more to the debugger, but you can indeed use it for this kind of thing - you need to simply see the type of an object you're getting from some code and find out what methods the object you got has.
It may be more useful to 'x' the object, and then go look at the source of the class the object's been blessed into to find out what you should do as opposed to what you can do. The 'x' command is pretty much 'print ref($obj)' crossed with Data::Dumper anyway.
You are looking for reflection in Perl. I just googled "Perl Reflection" without quotes and this came up:
http://coding.derkeiler.com/Archive/Perl/perl.beginners/2004-10/0291.html
Edit:
And this:
http://markmail.org/message/i5mzik56ry4zoxxq
Edit:
And this:
http://en.wikipedia.org/wiki/Reflection_(computer_science)#Perl