my const $FOO = 'bar';     # This is preferable, excuse my C++
my $FOO : const = 'bar';   # This is "more Perly"
[download]

my $FOO : const = 'bar'; # This is "more Perly"

my $foo is const = 'bar';
[download]

According to Exegesis 3.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

I see your point, and agree with you completely.

Why I used constant subroutines instead of doing use constant FOO => 'bar';? Because, as I saw everywhere else sub SOME_CONST{0}, and only now I discovered details about this.

Additionally I want to note that use constant FOO => 'bar'; internally does things similar to sub FOO(){'bar'} - I checked this right now.

Most important point of my initial message - that my places in programs, such as do{'a lot of debug stuff'} if DEBUG were NOT optimized away, whereas adding a prototype '()' to 'sub DEBUG' makes them to be optimized away!

Courage, the Cowardly Dog.
PS. Something fishy is going on there, or my name is Vadim Konovalov. And it's not.

It would be nice if you could declare inline functions explicitly rather than implicitly using this empty bracket "trick". I had no idea that Perl did this sort of magic for you under special circumstances. Maybe I haven't read enough of the latest Camel Book, because the older one didn't seem to make much of a big deal about it.

I think the reason I was so befuddled by it in the first place is because it didn't make any sense that Perl would do that sort of thing, I mean, other languages you've got to tell them to do this for you.

and just to help out the newer monks, why would this make a difference?

Sorry for not being 100% clear.

I was not advocating for usage of "almost constant subs" as opposed of usual subs. But I'll summarize this at the end of a message.

Okay, Now let us cover more details on things that you did not understood.

First, how I do 'deparse' and why I see that something was optimized away. You can read how to use deparse using command perldoc B::Deparse with many good examples.

Note how you can 'deparse' your snippet, or may be entire script:

C:\>perl -MO=Deparse -e "print 'this' if $x"
print 'this' if $x;
-e syntax OK
[download]

Okay. But what goes on when we see following:

C:\>perl -MO=Deparse -e "print 'this' if 0"
'???';
-e syntax OK
[download]

Those question marks are here because entire 'print' statement goes away. When you enter command perldoc B::Deparse again, there is an explanation there about those questions marks.

As an additional demonstration try to analyze following:

D:\>perl -MO=Deparse -e "sub MY_CONST(){'bla-bla'};$a=MY_CONST;print M
+Y_CONST;"
sub MY_CONST () {
    'bla-bla';
}
$a = 'bla-bla';
print 'bla-bla';
-e syntax OK
[download]

You see? That constant subroutine never called, instead it's value inlined everywhere, thus giving us an optimization.
Then again, let's change our sample snippet a bit.

D:\>perl -MO=Deparse -e "sub MY_CONST{'bla-bla'};$a=MY_CONST;print MY_
+CONST;"
sub MY_CONST {
    'bla-bla';
}
$a = MY_CONST();
print MY_CONST();
-e syntax OK
[download]

Everywhere our "almost constant sub" is called, thus slowing down things a bit.
But sometimes this may be considered good and intentional, because in this case you're able to override or redefine your sub in sub-modules.

Good.

Now why I said 'Not that good anymore' in my initial message:

C:\>perl -MO=Deparse -we "sub DEBUG{0}print 'this' if DEBUG;"
sub DEBUG {
    0;
}
print 'this' if DEBUG ;
-e syntax OK

C:\>perl -MO=Deparse -we "sub DEBUG(){0}print 'this' if DEBUG;"
sub DEBUG () {
    0;
}
'???';
-e syntax OK
[download]

Because in first case my program was a bit slower and bigger, because everywhere all my statements 'if DEBUG' were recalculataed again, and again, and again, whereas in second case they were just thrown away during compilation stage!

After I explained more details, let me explain why I was not advocating for either of them.
Okay, that was not my goal.
Additionally, may be sometimes module authors intentinally want to leave constant sub to be overridable in sub-class, or something like this.

But in most cases (like in family of Win32::* modules) they probably should be corrected to use really constant subroutines, so we'll gain speed and probably memory a bit.

Let me know if I still did not covered something.

Good luck,
Courage, the Cowardly Dog.
PS. Something fishy is going on there, or my name is Vadim Konovalov. And it's not.

Sorry

But the point still remains.

Courage, the Cowardly Dog.
PS. Something fishy is going on there, or my name is Vadim Konovalov. And it's not.

Which point? That perl's optimizer is pretty simple-minded? It is. Or that some modules aren't using the most constant constant subs that they can? They're not.

The modules in question probably need some updating. OTOH, you can, at runtime, override the non-constant constant subs, while you can't override the constant constant subs. (Whether the module authors were considering this or not is up in the air--they might've, or they might just have misread the docs)

I consider optimizer to be really good.

That "point" is about modules, especially core ones, which could be slightly improved.

But even more point for me is to learn from what I wrote and to write a bit better code by not using "almost constant subs" :)

Courage, the Cowardly Dog.
PS. Something fishy is going on there, or my name is Vadim Konovalov. And it's not.