True, but I think it’s cleaner when you’re actually calling the function to not
have to send a hashref. Small thing, of course, but I figure you write a
function once, but call it many times. I’d rather the function call be
cleaner/simpler than the function definition for that reason.
Sent
> you can do by array
Both of them are borring once you used the signatures but they are still
experimental.
Also: if you don't mind a new dependency: Function::Paramaters is so
much convenient.
regards
marc
hi
you can do by array
sub m4
{
my ( $self,$args ) = @_;
# $args contains
# $args->{'bla'} = blub
# $args->['do'} = whatever
}
as call ( example )
$obj->m4 ({ bla => blub , do => whatever });
holger
Am 02.01.20 um 21:40 schrieb danieljb...@icloud.com:
What if you want named
On 3/1/20 8:31 pm, Marc Chantreux wrote:
>> Any modern mailreader can easily tag messages as thread, so it's trivial to
>> avoid a given thread, as long as people don't fuck around with the
>> In-Reply-To info.
>
> i have to admit this isn't an argument: if most of the people don't read
> it, we
> Any modern mailreader can easily tag messages as thread, so it's trivial to
> avoid a given thread, as long as people don't fuck around with the
> In-Reply-To info.
i have to admit this isn't an argument: if most of the people don't read
it, we should have the ability to save bandwidth by
> Yes well, my point is if you want to make a piece of code
> incomprehensible, I don't think there is a language that will stop you.
indeed. but i now realize the counterpart is not true because everyone
has something different in mind when it comes to readability.
last example was yesterday:
On Thu, Jan 02, 2020 at 11:52:03PM +0100, Marc Chantreux wrote:
> > You have something like 3 lines of perl to play with ;)
>
> is there a todo list somewhere ?
More or less in my head, with lots of subprojects progressing at any given
time.
- I want to retire PackageLocator and have more
On Fri, Jan 03, 2020 at 09:43:21AM +1000, Stuart Longland wrote:
> On 3/1/20 8:50 am, Marc Chantreux wrote:
> >> Like this thread, or worse?
> > * long doesn't mean endless
> > * sharing points of view is never sterile (yours is inspired by other
> > ones, right?)
>
> I would say it's been
On 2/1/20 9:43 pm, Marc Chantreux wrote:
> arf ... i just tried to explain were this "linenoise" bullshit came from
> just in the answer i gave to frank
Yes well, my point is if you want to make a piece of code
incomprehensible, I don't think there is a language that will stop you.
I had a
On 2020-01-02 16:52, Marc Chantreux wrote:
You have something like 3 lines of perl to play with ;)
is there a todo list somewhere ?
find /usr/src -name '*.pm' | xargs grep XXX
Shows some promising results.
Edgar
regards
marc
On 2/1/20 8:48 pm, Marc Espie wrote:
>> I've seen some pretty ugly Python code too.
> Not to beat a dead horse, but most of the python configury stuff,
> including scons, is pretty shitty. Lots of really bad pseudo-OO stuf
> (hey let's use that cool feature just because we can)
Yeah, you won't
On 3/1/20 8:50 am, Marc Chantreux wrote:
>> Like this thread, or worse?
> * long doesn't mean endless
> * sharing points of view is never sterile (yours is inspired by other
> ones, right?)
I would say it's been highly educational.
Granted, this did not get off to a good start with the "let's
> You have something like 3 lines of perl to play with ;)
is there a todo list somewhere ?
regards
marc
On Thu, Jan 02, 2020 at 02:16:52PM -0500, Daniel Jakots wrote:
> On Thu, 2 Jan 2020 19:49:28 +0100, Marc Chantreux
> > some endless sterile debates
> Like this thread, or worse?
* long doesn't mean endless
* sharing points of view is never sterile (yours is inspired by other
ones, right?)
so
On Thu, Jan 02, 2020 at 04:10:43PM -0500, Paul Wisehart wrote:
> On Thu, Jan 02, 2020 at 09:12:42PM +0100, Marc Espie wrote:
> >
> > Here are my current guidelines for OpenBSD perl tools.
> >
>
> Can you eleborate in greater detail?
>
Not really, just go read the code and ask questions.
You
On Thu, Jan 02, 2020 at 09:12:42PM +0100, Marc Espie wrote:
>
> Here are my current guidelines for OpenBSD perl tools.
>
Can you eleborate in greater detail?
On Thu, Jan 02, 2020 at 02:40:25PM -0600, danieljb...@icloud.com wrote:
> What if you want named parameters? (i.e. sending a hash as your
> argument)
>
> sub m4
> {
> my $self = shift;
> my %args = @_;
>
> # and then optionally
> my ($arg1, $arg2, $arg3) = @args{qw/arg1 arg2
What if you want named parameters? (i.e. sending a hash as your
argument)
sub m4
{
my $self = shift;
my %args = @_;
# and then optionally
my ($arg1, $arg2, $arg3) = @args{qw/arg1 arg2 arg3/};
# or you can just use $args{arg1}, etc...
}
On Thu, Jan 02, 2020 at 09:12:42PM
On Thu, Jan 02, 2020 at 03:24:41PM -0500, Chris Bennett wrote:
> mod_perl, from reading the mailing list, looks like it will die off
> before long. Lack of developers and funding and interest given all the
> newer replacements.
Don't even think about using mod_perl these days.
Fast-cgi is the
I don't speak Python, but from what I've read, it has some serious
encoding problems compared to Perl.
This is a real problem in today's world of multiple encodings.
Apparently the guy writing about this is pretty hated for bringing up
this serious flaw. If the problem is true, he has examples,
On Thu, Jan 02, 2020 at 07:49:28PM +0100, Marc Chantreux wrote:
> On Thu, Jan 02, 2020 at 10:42:54AM -0600, danieljb...@icloud.com wrote:
> > I don't understand why people say that perl's flexibility is a negative.
>
> because sometimes, flexibility permit some endless sterile debates about
> the
On Thu, 2 Jan 2020 19:49:28 +0100, Marc Chantreux
wrote:
> some endless sterile debates
Like this thread, or worse?
On Thu, Jan 02, 2020 at 10:42:54AM -0600, danieljb...@icloud.com wrote:
> I don't understand why people say that perl's flexibility is a negative.
because sometimes, flexibility permit some endless sterile debates about
the coding style.
marc
> I will always lean towards idiot-proofing the code.
:))
fair enough.
regards
marc
I don't understand why people say that perl's flexibility is a negative.
Bad code is a negative. You can have bad or inconsistent code even in a
language like python that has very rigid syntax.
As long as you know perl well, you should be able to read any
well-written perl code.
To me, both of
On Thu, Jan 02, 2020 at 04:22:08PM +0100, Marc Chantreux wrote:
> hello,
>
> > > my %user = qw(
> > > login mc
> > > shell /bin/zsh
> > > );
> > > print $user{login};
>
> > my %user = ( login => 'mc', shell => 'bin/zsh');
> > is way more readable in that case, I
hello,
> > my %user = qw(
> > login mc
> > shell /bin/zsh
> > );
> > print $user{login};
> my %user = ( login => 'mc', shell => 'bin/zsh');
> is way more readable in that case, I think,
> and it does showcase what a *smart* quoting system can do.
well ... i prefer
On Thu, Jan 02, 2020 at 12:40:51PM +0100, Marc Chantreux wrote:
> the quoting system
>
> # qw( for a list of barewords )
> my %user = qw(
> login mc
> shell /bin/zsh
> );
> print $user{login};
I wouldn't write it that way
my %user = ( login => 'mc', shell =>
> Not sure about anyone else, but comparing the Python vs Perl example you
> gave above, I would still say Python is the nicer-looking language.
i was just saying that there is no need for yield in perl. now i can
show you tons of examples to demonstrate perl code is not only
more "unixish" but
hello Stuart,
> Heh, I've heard Perl described as executable line noise, and for sure,
> it will let you write code like that.
arf ... i just tried to explain were this "linenoise" bullshit came from
just in the answer i gave to frank
regards
marc
On Thu, Jan 02, 2020 at 07:34:22PM +1000, Stuart Longland wrote:
> On 2/1/20 12:30 am, Marc Chantreux wrote:
> > * the python community was unfair comparing the langages (using ugly
> > perl code and nice python counterparts). instead of taking time to
> > explain all the biases, perl
On 2/1/20 12:30 am, Marc Chantreux wrote:
> * the python community was unfair comparing the langages (using ugly
> perl code and nice python counterparts). instead of taking time to
> explain all the biases, perl community repetedly asserted that the
> authors of those article were
On 1/1/20 9:08 pm, Marc Espie wrote:
> On Tue, Dec 31, 2019 at 10:36:15PM +0100, Anders Andersson wrote:
>> Of course its age is showing in some areas but in my experience, those
>> things are actually still worked on, and have been fixed without major
>> incompatibilities (python3 anyone?).
> The
On Wed, Jan 01, 2020 at 03:30:44PM +0100, Marc Chantreux wrote:
why is this ? return is the perl yield. the only difference is that the
"exhausted" situation is on your own. so basically:
def count_from(x):
while True:
yield x
x = x + 1
naturals =
> Did you ever look at the suite of modules from John Syracusa (DB::Rose and
> the like) ? fairly clean and nice.
I had this under my radar but no one around be wanted to test anything
else but DBIxC so i never took time to read the code or use it.
regards
marc
On Wed, Jan 01, 2020 at 04:44:48PM +0100, Marc Chantreux wrote:
> > I still thing DBIx::Class is overkill. The DB::Rose stuff was way simpler
> > and I would have preferred for it to win.
>
> Well... i liked the simplicity until i had some cases like having 2
> different DBs with the same model:
hello,
> > what do you mean by this? prototypes are here for decades and signatures
> > are experimental and i guess it will be core in some releases.
> Stuff like
> $o->method { code }
ooohh right! this is a thing i also missed with perl (fixed in raku).
> > Template toolkit is still by far
On Wed, Jan 01, 2020 at 03:43:38PM +0100, Marc Chantreux wrote:
> hello,
>
> > The only thing that's really missing in perl is proper thread support.
> > Don't know if that's going to happen.
>
> seems ... complicated ...
Tell me about it. The only existing thread support was so clunky it got
hello,
> The only thing that's really missing in perl is proper thread support.
> Don't know if that's going to happen.
just to be sure: are you aware of the MCE module?
https://metacpan.org/pod/distribution/MCE/lib/MCE.pod
regards
marc
BTW. Also tcl has coroutines since a while:
https://www.tcl.tk/man/tcl8.6/TclCmd/coroutine.htm
Rodrigo.
hello,
> The only thing that's really missing in perl is proper thread support.
> Don't know if that's going to happen.
seems ... complicated ...
> I have a wish-list of things that are not that likely to happen, I would
> like to be able to use prototypes on methods, for instance.
what do you
hello,
as intro: i would like to make clear that i'm not promoting perl (my go
to langage for scripting is now raku by far) but as i was a member of the perl
community more than 20 years, i have some opinions about it.
> felt like a random hack, especially compared to ruby. The only thing I
>
On Tue, Dec 31, 2019 at 10:36:15PM +0100, Anders Andersson wrote:
> Of course its age is showing in some areas but in my experience, those
> things are actually still worked on, and have been fixed without major
> incompatibilities (python3 anyone?).
The only thing that's really missing in perl
On Tue, Dec 31, 2019 at 4:30 PM Marc Chantreux
wrote:
>
> On Tue, Dec 31, 2019 at 06:57:02AM -0600, Daniel Boyd wrote:
> > As one of the few remaining people out there who considers perl to be
> > their favorite language—starting to wonder if it’s just me and Larry
> > Wall at this point—I’d like
44 matches
Mail list logo
