Hello,
I'd vote for the OO-style.
My reason is that the major criteria should be the reader perspective.
It should be as clear as possible what's going on in the main code
even if the reader doesn't know the hottest p6 tricks!
What you are doing here is: two operations on the same thing (the pidf
On Fri, 2009-01-02 at 00:30 +0200, Leon Timmermans wrote:
> I can't help wondering "why does pid_file_handler need to be split up
> in the first place?" Why wouldn't it be possible to simply call
> pid_file_handler after become_daemon?
Two answers:
1. If an error occurs that will not allow the PI
I can't help wondering "why does pid_file_handler need to be split up
in the first place?" Why wouldn't it be possible to simply call
pid_file_handler after become_daemon?
Regards,
Leon Timmermans
On Thu, Jan 1, 2009 at 10:34 PM, Geoffrey Broadwell wrote:
> In the below Perl 5 code, I refactore
In the below Perl 5 code, I refactored to pull the two halves of the PID
file handling out of init_server(), but to do so, I had to return a sub
from pid_file_handler() that acted as a "continuation". The syntax is a
bit ugly, though. Is there a cleaner way to this in Perl 6?
##
sub init_ser
On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
> Just stumbled across this, but I can't tell from S09 if this is a bug or
> feature:
>
> $ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl'
> {"a" => undef}
It's a bug. In order to simplify the slicing implementation
Rakudo currently aut
pugs-comm...@feather.perl6.nl wrote:
--name :name
--name=value:name
--name="spacy value":name«'spacy value'»
--name='spacy value':name«'spacy value'»
--name=val1,'val 2',etc :name«val1 'val 2' etc»
+-n
