d mandating a clean core namespace
so that we don't have collisions.
>
> -Original Message-
> From: Diab Jerius
> Sent: Thursday, May 23, 2019 10:32 PM
> To: pdl-devel@lists.sourceforge.net ; Ed .
> Subject: Re: [Pdl-devel] PDL release; I'm volunteering.
>
&g
Just to be clear; you're saying that Perl (which seems quite nice)
illustrates the plus side of things being methods?
-Original Message-
From: Diab Jerius
Sent: Thursday, May 23, 2019 10:32 PM
To: pdl-devel@lists.sourceforge.net ; Ed .
Subject: Re: [Pdl-devel] PDL release
On Thu, May 23, 2019 at 1:27 PM Diab Jerius wrote:
> My philosophy is that the only things that should be methods are those
> that require knowledge of the private innards of a piddle, or that are
> required for implementing overloaded operators (useful for subclassing
> PDL. I had to write overl
of approaches that can work (this is Perl after all).
Particularly when we're dealing with a group of users that might not
eat objects for breakfast.
> What would your list of PDL* methods be?
I'll have to think about that a bit.
>
> -Original Message-
> From: Dia
e-
From: Diab Jerius
Sent: Thursday, May 23, 2019 3:11 PM
To: pdl-devel@lists.sourceforge.net
Subject: Re: [Pdl-devel] PDL release; I'm volunteering.
I think I've officially been Warnocked.
I've been working my way through a number of areas (graphics, ppcode,
module layout,
I think I've officially been Warnocked.
I've been working my way through a number of areas (graphics, ppcode,
module layout, documentation, etc), but haven't finalized a proposal
for what I would hope to accomplish as the next release manager.
If that's what's holding up any response to my offer,
Hi,
I'm willing to marshal the next release of PDL.[0]
PDL needs to keep going while its future successor is developed and
planned.[1] While PDLA is promising, it's not a simple drop-in
replacement, and perhaps shouldn't be.
To move PDL into its proper place in the Perl ecosystem[2] requires a
l
