My understaning is that Foo->hello & hello are basically the same except the former is calling class method and passing 'Foo' to hello as the first arg, but the later is calling a subroutine and will not pass 'Foo'.

That's almost entirely correct. The method form, whether the invocant is the name of a class or an object, always performs dispatch. That is, Perl looks up the most appropriate method based on the given class. Then, Perl invokes that method and passes the invocant as the first argument.

The function form is a direct invocation of the subroutine of that name in the current package. There's no dispatch lookup step to find the most appropriate method. You get what's there, and the first argument is whatever you've passed in explicitly.

My understaning is that Foo->hello & hello are basically the same except the former is calling class method and passing 'Foo' to hello as the first arg, but the later is calling a subroutine and will not pass 'Foo'. How do you think?

I think you understand, but your wording leaves to be desired. The same sub is called in both cases; the difference is in how it's called:

Foo->hello & hello are basically the same except the former is calling hello as a class method and passing 'Foo' (or whatever's left of the arrow) as the first arg, but the latter is calling hello as a subroutine and will not pass 'Foo'.

One difference that wasn't mentioned is that inheritance will come into play when hello is called as a method.

{ package Foo; sub hello { ... } }
{ package Bar; our @ISA = 'Foo'; }

Foo->hello('world');   # Foo::hello('Foo', 'world')
Bar->hello('world');   # Foo::hello('Bar', 'world')
Foo::hello('world');   # Foo::hello('world')
Bar::hello('world');   # hello not found in Bar
[download]

I think the purpose of these class method calls is to initialize some class variables

And maybe even create subs, yes.

found them with grep, though:

1:53 spiceman@cynic ~/perl5/lib/perl5 % grep -R 'sub add_columns ' DBIx
DBIx/Class/CDBICompat/ColumnGroups.pm:sub add_columns {
DBIx/Class/CDBICompat/ColumnCase.pm:sub add_columns {
DBIx/Class/DynamicDefault.pm:sub add_columns {
DBIx/Class/TimeStamp.pm:sub add_columns {
DBIx/Class/ResultSource.pm:sub add_columns {
DBIx/Class/ResultSourceProxy.pm:sub add_columns {

1:53 spiceman@cynic ~/perl5/lib/perl5 % grep -R 'sub table ' DBIx
DBIx/Class/ResultSetManager.pm:sub table {
DBIx/Class/ResultSourceProxy/Table.pm:sub table {

1:53 spiceman@cynic ~/perl5/lib/perl5 % grep -R 'sub load_components ' .
./Class/C3/Componentised.pm:sub load_components {

I found the corresponding classes that these three class methods belong to:

DBIx::Class::ResultSourceProxy::Table
table()
add_columns()

Class::C3::Componentised
load_components()

And I also know Class::C3::Componentised is the parent class of DBIx::Class that is the parent of Item, so this makes sense. But I don't know the relationship between DBIx::Class::ResultSourceProxy::Table and DBIx::Class.

Any idea?

Taking an educated guess with grep is indeed the easiest path sometimes.

load_components loads modules and adds them as base class (kinda like use base does).

load_components('Core') loads DBIx::Class::Core and makes DBIx::Class::Core a base class of your class.

DBIx::Class::Core similarly uses load_components loads a number of modules (including DBIx::Class::ResultSourceProxy::Table) and adds them to its list of base classes.

package Result::Item;

use strict;
use warnings;

use base 'DBIx::Class';

__PACKAGE__->load_components( "InflateColumn::DateTime", "Core" );

print "Parents of Result::Item:\n";
print "$_\n" for @Result::Item::ISA;
print "\n";
print "Parents of DBIx::Class::Core:\n";
print "$_\n" for @DBIx::Class::Core::ISA;
[download]

Parents of Result::Item:
DBIx::Class::InflateColumn::DateTime
DBIx::Class::Core
DBIx::Class

Parents of DBIx::Class::Core:
DBIx::Class::Relationship
DBIx::Class::InflateColumn
DBIx::Class::PK::Auto
DBIx::Class::PK
DBIx::Class::Row
DBIx::Class::ResultSourceProxy::Table
DBIx::Class
[download]