Re^3: Canon concerning coderef calls?

Chromatic's OO way

I wouldn't really call that an OO way. Sure, it uses can as a class method on main, but that's where the OOishness ends. It returns a plain coderef and executes it with a different dereferencing syntax than you used. I believe it is also the only alternative that does not use a symbolic reference.

To reinforce the point about being a plain coderef, this works:

foreach (@list) {
    my $coderef = main->can($_);
    &$coderef($_);
}
[download]

And this does too, if you really want to get rid of all the pointy arrows:

foreach (@list) {
    my $coderef = UNIVERSAL::can('main', $_);
    &$coderef($_);
}
[download]

Update: and if you want to see what I would consider the "OO way":

foreach (@list) {
    main->$_($_);
}
[download]

But, frankly, I think that's very ugly. It uses a symbolic reference too. I would use can as chromatic originally did.

Comment on Re^3: Canon concerning coderef calls? Select or Download Code

Replies are listed 'Best First'.
Re^4: Canon concerning coderef calls? by NetWallah (Canon) on Nov 16, 2004 at 03:28 UTC
I agree with all your notes, revdiablo. I particularly like the self-documenting "UNIVERSAL::can" call, although research shows that the "can" method (or allegedly exported sub) does not really exist in any module - documentation says it is built into perl. Earth first! (We'll rob the other planets later)	[reply]
Re^5: Canon concerning coderef calls? by revdiablo (Prior) on Nov 16, 2004 at 06:06 UTC
research shows that the "can" method (or allegedly exported sub) does not really exist in any module - documentation says it is built into perl I suppose it all depends on what you mean by "built into perl." It's true that it's part the perl core, and can be relied on being there. But that's only because UNIVERSAL is the base class for all classes. If you run `perldoc -f can`, or browse through perlfunc, you will see that `can` is not a builtin function in the strict sense of the term.	[reply] [d/l] [select]