Arrow Notation vs. Colon Notation
Marc
Lib->load_config("config.dat");
Lib::load_config("config.dat");
Is this just a case of TIMTOWTDI or is there a difference in how they do what they do?
Marc
Uri Guttman
M> I've noticed that the following two lines seem to be equivalent when calling a sub from a module called Lib.pm:
Lib-> load_config("config.dat");
M> Lib::load_config("config.dat");
M> Is this just a case of TIMTOWTDI or is there a difference in how
M> they do what they do?
they are actually very different. the :: call is just a plain sub call
with a fully qualified path. if the sub was imported into the current
package you wouldn't even need the Lib:: part.
the other is a class method call. it has two major differences. first it
will pass its class (or object, the arg before ->) as the first arg in
the call. the second thing is that it will search the class hierarchy
(using the package global's @ISA) to find that method if it isn't in the
Lib class.
so don't think they are even similar as one is a sub call and the other
is a class method call. they aren't interchangeble at all
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
Marc
> so don't think they are even similar as one is a sub call and the other
> is a class method call. they aren't interchangeble at all
Yep, you're correct. Why is everything so simple once someone explains it to you??? =;)
That also cleared up a strange problem I was having with my code. Boy, am I embarrassed. On the plus side, this ordeal has helped to solidify it for me, so I guess it's O.K. to make stupid mistakes once in awhile, no?
Thanks, Uri.
Marc
jbiskofski
Cheers!
- biskofski
> --
> To unsubscribe, e-mail: beginners-...@perl.org
> For additional commands, e-mail: beginne...@perl.org
> http://learn.perl.org/
>
>
Shawn H Corey
> the other is a class method call. it has two major differences. first it
> will pass its class (or object, the arg before ->) as the first arg in
> the call. the second thing is that it will search the class hierarchy
> (using the package global's @ISA) to find that method if it isn't in the
> Lib class.
Not true in all cases:
#!/usr/bin/env perl
use strict;
use warnings;
package Foo;
sub foo {
print "foo\n";
}
package main;
Foo::foo();
Foo->foo();
Foo::bar();
__END__
The difference here is that `Foo:bar()` gives a run-time error; where
`Foo->bar()` gives a compile-time error.
Compile-time errors are always reported. Run-time errors are only
reported if the subroutine is called. If you have something like this,
the script would only stop for some rare condition:
if( come_rare_condition ){
Foo::bar();
}
Not something you want to discover after the code is in production. :)
--
Just my 0.00000002 million dollars worth,
Shawn
Confusion is the first step of understanding.
Programming is as much about organization and communication
as it is about coding.
The secret to great software: Fail early & often.
Eliminate software piracy: use only FLOSS.
Rob Dixon
I'm not sure what you mean here Shawn. Errors are generated at run time
in both cases, so code like
if (0) {
Foo::bar();
}
if (0) {
Foo->bar();
}
will generate no errors at all. In particular the method call cannot
generate a compile-time error as Perl supports dynamic binding in order
to implement object-orientation.
It would be possible to generate calls to undefined subroutines at
compile time, but because the symbol table can be modified at run time
with such trickery suck as *Foo::bar = \&Foo::foo it is also left until
run time to report any such errors.
Rob
Uri Guttman
RD> I'm not sure what you mean here Shawn. Errors are generated at run time
RD> in both cases, so code like
RD> if (0) {
RD> Foo::bar();
RD> }
RD> if (0) {
Foo-> bar();
RD> }
RD> will generate no errors at all. In particular the method call cannot
RD> generate a compile-time error as Perl supports dynamic binding in order
RD> to implement object-orientation.
what he said. there is no compile time error in shawn's code.
Rob Dixon
>
> It would be possible to generate calls to undefined subroutines at
> compile time, but because the symbol table can be modified at run time
> with such trickery suck as *Foo::bar = \&Foo::foo it is also left until
> run time to report any such errors.
My apologies. This should read:
It would be possible to raise errors regarding calls to undefined
C.DeRykus
> On 11-07-20 07:03 PM, Uri Guttman wrote:
>
> > the other is a class method call. it has two major differences. first it
> > will pass its class (or object, the arg before ->) as the first arg in
> > the call. the second thing is that it will search the class hierarchy
> > (using the package global's @ISA) to find that method if it isn't in the
> > Lib class.
>
>
> The difference here is that `Foo:bar()` gives a run-time error; where
> `Foo->bar()` gives a compile-time error.
An INIT{} which executes just after compilation can help
pinpoint when runtime starts:
....
INIT { print "runtime starting...\n"; }
__END__
runtime starting...
foo
foo
Undefined subroutine &Foo::bar called ....
--
Charles DeRykus