in reply to Mass Class Confusion - Who calls what how?

my $response = $self->{kiosk}->process($msg)

here you are attempting to execute method process() from an object which is held in $self->{kiosk}. Now the latter is undefined as you never set it.

You can set the kiosk object inside $server after you create the kiosk like this:

my $server = MyWebServer->new($kiosk_port);
print "INSTANTIATING KIOSK ==============================\n";
$kiosk = Kiosk->new($placard, $server, $debug_level);
#### let the server know what the kiosk obj is:
$server->{kiosk} = $kiosk;

[download]

That said, the "proper" way would be to create accessors or getter and setter methods to set the kiosk object and other parameters internal to a class with all the proper checks, if kiosk is empty and what not. The boilerplate code can be avoided and "properness" inserted automatically by using an OO system, for example Moose (edit: or Moo). It is not something that I ever used as I like my own OO style, but using such a system in a production environment gives you certain code-quality guarantees. Although you can entirely do without it (and skip a few kilos of cargo).

One of the aims of OO is to black-box your program units into classes which do complex things internally but provide you with the simplest possible API for telling them what to do and on what data. Like, initialise($kiosk);, is_connected(), do_transaction(10). Making a class with tens of internal variables all exposed defies using OO in the first place and soon complexity will either kill your program or introduce so many bugs. From your code: you don't know which variable is primary, like $self->{kiosk} and which is derived, $self->{kiosk_id} which I assume could be set via the kiosk object. Perl's OO beauty, in my opinion, is its light-weight-ness. But it allows a lot of things which are generally critisised like indiscriminately exposing variables.

So,

package Server;
...
sub new {
  ...
  $self = {kiosk=>undef};
  ...
  return $self;
}
sub kiosk {
  my $self = shift;
  my $m = shift;
  if( defined $m ){
    die unless $self->_set_kiosk($m);
  }
  return $self->{kiosk}
}
# returns 0 on failure, 1 on success
sub _set_kiosk {
  my $self = shift;
  my $akiosk = shift;
  if( ! $akiosk->connected() ){ return 0 }
  $self->{kiosk_id} = $akiosk->id();
  print "setting the kiosk to this: " . $akiosk. "\n";
  return 1;
}
sub do_transaction {
  my $self = shift;
  return 0 unless defined $self->{kiosk};
  ...
}

[download]

OO is one of the great tools programmers were given ever (that and the hashtable!). Use it wisely and to your advantage.

bw, bliako

Edit: this is related: Inheritable configuration options.... but with default values?

Replies are listed 'Best First'.
Re^2: Mass Class Confusion - Who calls what how?
by holandes777 (Scribe) on Feb 21, 2020 at 13:07 UTC

    your solution is correct. Passing in the $kiosk object makes it accessible to the message handler routine

    print "INSTANTIATING KIOSK ==============================\n";
my $kiosk = Kiosk->new($placard, $server, $debug_level);
# start the server on port __
print "INSTANTIATING SERVER port $kiosk_port =========================
+=====\n";
my $server = MyWebServer->new($kiosk_port);
$server->run();
$server->{kiosk} = $kiosk;

    [download]

    this part in HTTP::Server::Simple::CGI; sees it just fine and responds properly ... so THANK YOU. 

        sub handle_request {
        my $self = shift;
        my $cgi  = shift;
        my $json_string = $cgi->param('POSTDATA');
        # { "type":"cardCheck", "date":"1482307795601", "lang": "EN", 
+"machineName":"PLUSMAKM", "cardNumber":"1234567890", "PIN": "1234" }
        print "json_string=$json_string\n";
        $json_dict = decode_json $json_string;
        print "json_dict=" . Dumper($json_dict) . "\n";
        my $response = $self->{kiosk}->process($json_dict);
        print "response=$response\n";
        return $response;
    }

    [download]

    there was one issue in fully implementing your solution (the code worked without it). When you add the "new" method to HTTP::Server::Simple::CGI;object as follows you get an execution error

       sub new {
        my $self = {};
        $self->{class} = $class;
        $self->{kiosk} = undef;
        bless($self,$class);
        return $self;
    }

    [download]

    Can't locate object method "run" via package "main" at http_server.pl line 56, <CONF> line 35. line 56 is

    $server->run();

    [download]

    this was the original reason I requested help. Now that I see the code a bit more I guess the question is "how do you exend the HTTP::Server::Simple::CGI; object, but that is another topic. SO I thank you for an excelent easy solution and, if you have any ideas about the ast question, I would love to hear it so I can gain more knowledge about OO in Perl.

[reply]
[d/l]
[select]

      You will be benefited from a Perl OO tutorial, here is one picked at random http://wwwacs.gantep.edu.tr/docs/perl-ebook/ch19.htm. There is also the official tutorial: perlootut

      I assume you have read Re: Mass Class Confusion - Who calls what how?

      To inherit from a class just use (after the package declaration):

      use parent 'HTTP::Server::Simple::CGI';

      There is also something similar in HTTP::Server::Simple's documentation...

      But do you want that? Or do you want to instantiate a HTTP::Server::Simple::CGI object in your server and then call its run() method via your own run() whenever needed like so:

      sub new {
    my ($class, $params) = @_;
    $self = {server_simple_cgi => undef, ...};
    bless $self => $class;
    $params = {} unless defined $params;
    $self->{$_} = $params->{$_} for keys %$params;
    if( ! defined $self->{server_simple_cgi} ){
        $self->{server_simple_cgi} = HTTP::Server::Simple->new();
    }
    ...
}
sub run {
    my ($self, $params) = @_;
    # do something with params
    # and then run the server, it must be a valid object by now
    $self->{server_simple_cgi}->run()
}

      [download]

      In this way you keep total control of your server and allow callers to control it only via certain API calls you provide (like the above run()) which may do additional checks, filter out things, before calling the server's, "real" run(). Note that this IS NOT about security (e.g. who is allowed to call what). Because a caller could still call $self->{server_simple_cgi}->run() (there are ways to avoid that: Objects with Private Variables). I am talking about the clarity and simplicity of the API you are building.

      bw, bliako

[reply]
[d/l]
[select]

        This is a much better Perl OO primer than the one I previously linked: https://www.perl.com/article/25/2013/5/20/Old-School-Object-Oriented-Perl/ . (I am glad to see that it sends parameters to functions as a hashtable by reference instead of by value).

        But I forgot to mention one important detail. Huge really. If the inherited (child) class has its own constructor (overriding - or more brutally, overwriting - the parent's constructor) then you must call in it the parent's constructor yourself before you do any more initialisation. Like so:

        package Child;
use parent 'Parent';
sub new {
    my ($class, $params) = @_;

    # call parent's constructor first with the given parameters
    # the parent should ideally filter out the parameters
    # that do not concern it and ignore them rather than complaining a
+bout illegal params
    my $self = $class->SUPER::new($params);
    # at this point $self has all Parent's initialisation
    # (whatever was done and set in its constructor).

    # Now do local initialisation on $self which is Parent's self (a {
+} in most cases)
    ...
    $self->{child_extra_property_1} = 12; # for example
    ...

    # and bless to Child - actually that's a re-bless because calling
    # Parent's constructor blessed $self to be an object of class 'Par
+ent'
    # so now make it of class 'Child'
    bless $self => $class;
    return $self;
}

        [download]

        bw, bliako

[reply]
[d/l]

In Section Seekers of Perl Wisdom