I have my own module which has some dependencies which are listed in its Makefile.PL (and I am using ExtUtils::MakeMaker). I want to install/upgrade all the dependencies listed in the Makefile.PL without first doing a make install in my module. Essentially: I take my distribution to another computer, I unpack it and then I want to be able to tell it to install all dependent modules. I have seen something like this cpanm --installdeps DISTDIR but that stops soon without complains but without doing any install/upgrades.

It's important that I don't install the module itself (as in make install) because it is in development and I want to work with its blib/lib at the moment. But I do want all its dependencies to be installed system-wide as Administrator.

I've decided to persevere with Mojolicious for a new web application^* and am seeking expert advice on using Template as the templating engine. A search has pulled up this blog post which seems promising but (a) it's just a blog post from someone else who was apparently also rather stumbling about just trying to get it to work and (b) is from 12 years ago. So, my question is: is the advice contained in that blog post reflective of good practice for using TT with Mojolicious these days?

Before you ask, the reason to avoid the built-in templating engine is that I have tried to use Mojolicious a few times in the past and each time have run into problems and had to abandon it. Just in case that happens again, I would rather start with my templates in a format which I know I can re-use in another framework.

^* Expect a meditation in due course (and probably further SoPWs as things progress :-)

use strict;
use warnings;
use Benchmark 'cmpthese';

cmpthese -1, { map { $_ => \&$_ } 'a' .. 'g' };

                                         sub a {eval 1 for 0 .. 999}
{use feature ':5.10';                    sub b {eval 1 for 0 .. 999}}
{use 5.010;                              sub c {eval 1 for 0 .. 999}}
{no feature ':all'; use feature ':5.10'; sub d {eval 1 for 0 .. 999}}

{use feature 'say';                   sub e {eval 1 for 0 .. 999}}
{                   no feature 'say'; sub f {eval 1 for 0 .. 999}}
{use feature 'say'; no feature 'say'; sub g {eval 1 for 0 .. 999}}
[download]

Results:

   Rate    d    b    e    g    f    a    c
d 119/s   --  -0% -18% -23% -25% -53% -53%
b 119/s   0%   -- -18% -23% -25% -53% -53%
e 145/s  22%  22%   --  -7%  -8% -43% -43%
g 155/s  30%  30%   7%   --  -2% -38% -38%
f 158/s  33%  33%   9%   2%   -- -37% -37%
a 252/s 112% 112%  74%  62%  59%   --  -0%
c 252/s 112% 112%  74%  63%  59%   0%   --
[download]

Looks like feature pragma leaves some nasty attribute somewhere if mentioned. String eval is slow as it is already, why make it even slower. Well, partly tongue-in-cheek useless entertainment, but still partly: I used to declare like "c" case, then made a habit of explicitly declaring like e.g. "e"; now what? perfectionist in me urges to return to habits of years long gone. The "d" is there because feature says it should be exactly the same as "c".

This is hard to google for—is there a conventional name for this format: you've got too many files to put them all in $directory so you put them in $directory slash substring($name,0,1) slash substring($name,1,1) so that for example your file foo.jpg is found in /var/images/f/o/foo.jpg ?

Intro

I've been looking at the docs for the new 'class' OO in upcoming Perl versions.

While i agree that Perl would benefit from a modern OO system, i think this new system shouldn't give up any of the flexibilities ye olde 'bless' provides.

Before i go into details, i must admit that i'm not a huge fan of the "attributes" stuff that most OO system use. Or at least not to the extend they are used anyway. I've seen code that uses like 4-5 attributes for a single class and just as much for a variable. I call this C++ line noise. Yes, it makes the code more concise(1), but when you have to spend a minute per line of code just to understand just the implication of these flags, they are not what i call helpful. Going forward, the new 'class' system will have to be very carefully design to avoid making a mess with attribute feature creep.

I also understand that 'class' is still in the early stages, so i can only look on what has been designed so far. My main questionmarks are:

• Abort object creation?
• Constructor not proper functions?
• Deciding when to call parent constructor?

Let's look at those in detail:

Abort object creation?

One of the nice things about 'bless' is that constructors are just functions with return values. This allows the constructor a lot of flexibility. One of those is to not construct an object under some circumstances. Something like this:

package Foo::Bar::UrlHandler;

sub new($proto, %config) {
    my $class = ref($proto) || $proto;

    if(!defined($config{url})) {
        # No URL given, don't know what to do next
        return;
    }

    my $self = bless \%config, $class;

    return $self;
}
[download]

The caller can easily check if things worked out:

my $handler = Foo::Bar::UrlHandler->new(url => 'http://perlmonks.org')
    or do_some_error_handling();
[download]

From what i understand, a 'class' is pretty much required to be created, no matter if that makes sense with the given parameters. This will probably make error handling/detection in the caller more complicated. And no, eval() is seldomly the solution to such problems but many times the cause of them.

Constructor not proper functions?

From the design, it seems you don't write the constructor as a proper function, you can only 'ADJUST()' what it does. This has a few implications that make it much less flexible than bless():

No "named" constructor

Modules like DBI (among others) make use of the fact that bless() can run in arbitrarily names constructors. For DBI, this is connect(). In my opinion, this makes it much clearer to the user of this module that constructing an new instance is not only an in-memory operation, it also connects to the server.

No option for multiple constructors

In my projects, i have a few modules that provide multiple constructor. For example, there might be a classic new(list-of-parameters), but also a newFromConfig(filename) that takes a filename to a configuration file. This makes especially sense when using sub signatures. Another example would be, say, a file parser that has a newFromFile() and newFromUrl() method.

Yes, you can achieve this by subclassing with the new 'class' OO, but that can make the code harder to maintain, especially if only the initialization differs.

No simple "factories"

I sometimes use the concept of "factories", e.g. modules that decide on given parameters which object to return. In keeping with the example of the UrlHandler above, something like this isn't too uncommon:

package Foo::Bar::UrlHandler;

sub new($proto, %config) {
    my $class = ref($proto) || $proto;

    if(!defined($config{url})) {
        # No URL given, don't know what to do next
        return;
    }
    
    if($config{url} =~ /^http\:/) {
        return Foo::Bar::UrlHandler::HTTP->new();
    } elsif($config{url} =~ /^file\:/) {
        return Foo::Bar::UrlHandler::FILE->new();
    }

    # Invalid URL?
    return;
}
[download]

Deciding when to call parent constructor?

Sometimes it's useful to decide WHEN and IF(2) to call the parent constructor. I don't see how that is properly handled by the 'class' OO.

sub new($proto, %config) {
    my $class = ref($proto) || $proto;

    # Override the default template
    $config{htmltemplate} = 'righttoleft.tt';

    # Call parent constructor to load and parse template
    my $self = $class->SUPER::new(%config);
    
    # Re-bless
    bless $self, $class; # Re-bless with our class
    
    $self->do_our_own_stuff();
    
    return $self;
}
[download]

Conclusion

The new 'class' OO is a long overdue project and i thank the developers for their hard work. But at this early stage, it seems to be only a copy of other programming languages, without the flexibility Perl can (and currently does) provide when it comes to object orientation.

I'm using Perl (and ignore the Moo* stuff(3)) because i can shape the language to fit the problem. If we go the way in which we have to shape the problem to fit the language, we all might as well switch to there-is-only-one-way-to-do-it languages like C++, Java or TypesScript.

Yes, 'class' has the potential to make object oriented code easier to read and write, and i'm certainly all for that. We just need to make sure that it turns out TIMTOWTDI enough not to feature the same headaches as Java or C++. I can only talk about this from one own, small personal viewpoint, but because of (not "despite of"!) the flexibility of the old bless() OO and the typelessnes of Perl variables, in the last two decades i was able to single-handedly write a big web framework and implement multiple commercial systems in Perl.

Footnotes:
(1) just as $_ does. Which makes following code flow (and debugging it) a huge pain. Use $_ is banned in my projects.

(2) Sometime you override, sometime you enhance, sometimes the parameters to new() tell you what to do

(3) Combining the rigidity of C++ with the speed of Windows Vista somehow never appealed to me.