in reply to Re: OO modules
in thread OO modules

An OO module *is* a library. The words module and library can be used for each other interchangeably. For OO, you must have a module/library file. This file contains the "class" that your objects will be blessed into. To make things more confusing, a class is called a "Package" in Perl.

To nitpick a bit on that: it is in fact the other way round. First comes the namespace which is called a package. It is declared with the keyword package followed by the package name, optionally followed by a block containing all what belongs to that namespace. Without that block which defines it, the packages scope ends when another namespace (or package) is declared, when the enclosing scope ends or at end of file. This namespace can be OO, but must not be. Any number of packages may be declared in whatever perl code, and packages can be switched within.

For any collection of functions to be a module or library, OO or not, it must be contained in its own file - otherwise it is not modular.
For a library or module to be OO, it must declare a namespace and its functions must take into account that their first argument is either an object (a reference "blessed" into the class, i.e. tagged with it) or the class itself (which happens to be the package name).

When useing a module via its namespace (package) name, it must be contained in a file relative to any directory in perls include path, where its relative path is the package name with .pm appended, and the double colons :: within are substituted by the directory path separator. But require provides more rope.

So, package, module and OO - or namespace, library and namespace aware function collections - are loosely coupled concepts in the sense that each can be used on its own. It is perfectly feasible to write a program which uses OO but doesn't use any module, where all classes are lumped together into one file - in which case it isn't modular. This is what App::FatPacker does.

The path resolution thingy of included files is a different thing, explained in use and require. A package directive within isn't mandatory if it isn't OO, its last statement must just yield some true value:

# file Useless/Nothing.pm 1;

This, while being useless, compiles and adds a key/value pair to %INC but doesn't create/add the namespace Useless::Nothing. Any symbols defined in such a file without explicit package directive are hooked into the package in scope where the use occurs.

Oh, and

bless() is the class method that actually makes a standard perl reference type an object of your class.

bless() is a function, and a method of package CORE. So to work as a method, the invoking variable needs to be blessed into package CORE first...

qwurx [shmem] ~> perl -E '$foo = bless {}, "CORE"; $foo->bless("blorf" +); say $foo' blorf=HASH(0x1e53e78) qwurx [shmem] ~> perl -e '$foo = bless {}, "blorf"; $foo->bless("CORE" +); say $foo' Can't locate object method "bless" via package "blorf" at -e line 1. qwurx [shmem] ~> perl -e '$foo = {}; $foo->bless("blorf"); say $foo' Can't call method "bless" on unblessed reference at -e line 1.

Which also means that you can have a class method bless, but that's somewhat useless, except for obfuscation and other sophisticated use cases:

package Whatever; sub bless { my ($object, $class) = @_; return bless $object, $class; }

That would be a method for object migration ;)

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'