http://www.perlmonks.org?node_id=1019819
Wiggins has asked for the wisdom of the Perl Monks concerning the following question:

Please be tolerant, and read through to the end. I am trying to wrap my head arround some OO Perl that doesn't match the style of any of the examples I can find. The code ths that Msg.pm from
"Advanced Perl Programming By Sriram Srinivasan 1st Edition 1997".
Only some parts are in the book, but it is all tied together in
" ftp://ftp.oreilly.com/published/orielly/nutshell/advanved_perl/examples.tar.gz".

Puzzlement #1)
This code comes from Msg.pm. It is the first sub in the file, following some glocal hashes and such.

# Send side routines sub connect { my ($pkg, $to_host, $to_port, $rcvd_notification_proc) = @_; # Create a new internet socket my $sock = IO::Socket::INET->new ( PeerAddr => $to_host, PeerPort => $to_port, Proto => 'tcp', Reuse => 1);
Connect lists 4 paramaters, 3 are used here.
The calling code in "msgdemo.pl":
use Msg; ... foreach $prog (@ARGV) { my $conn = Msg->connect($host, $port, \&rcvd_msg_from_server); die "Client could not connect to $host:$port\n" unless $conn; print "Connection successful.\n";

'new_server()' is called with only 3 arguments, not 4! But it works. The '$pkg' is used a bit later in this code:
# Create a connection end-point object my $conn = bless { sock => $sock, rcvd_notification_proc => $rcvd_notification_proc, }, $pkg;
From the comment, an object was created. The reference is the anonymous hash with 2 members, and the class name is what? $pkg appears to be an undefined scalar?

Puzzlement #2
Further down in the code is a small subroutine that sets the flush value to true for the 'conn':

sub send_now { my ($conn, $msg) = @_; _enqueue ($conn, $msg); $conn->_send (1); # 1 ==> flush ?????? }
From the prior 'bless', a $conn has no methods, but the
$conn->_send (1);
looks like _send is a method of the $conn object. Is that a shorthand or alternate form of
_send ($conn,1);
of a Perl convention to have a non object method work with this object.

This --server code listens on only one port, and I am trying to generalize it to manage multiple listen sockets and support UDP as well as TCP.

It is always better to have seen your target for yourself, rather than depend upon someone else's description.