> and override.pm.
I meant overload.pm - sorry, was a placeholder and hit "send" a little too quickly.
Brett
??????? Original Message ???????
On Saturday, June 19th, 2021 at 8:41 PM, mah.kitteh via perl5-porters <perl5-porters@perl.org> wrote:
> ??????? Original Message ???????
>
> On Saturday, June 19th, 2021 at 3:44 PM, Darren Duncan darren@darrenduncan.net wrote:
>
> > On 2021-06-19 7:31 a.m., Ovid via perl5-porters wrote:
> >
> > > Tom wrote:
> > >
> > > /I'd claim that "modern" is not a useful term to be using in any
> > > documentation here - it's not descriptive, and the way it's used is more
> > > subjective than anything.
> > > /
> > >
> > >
> > > I've very annoyed by that comment because, damn it, it's spot on. I'll update
> > >
> > > the RFC when I have figured out a more appropriate phrasing. Or maybe Paul will.
> > >
> > > Dunno.
> >
> > I completely agree with this, but it hadn't occurred to me before.
> >
> > Using "modern" to describe something is so over-used its lost all meaning. It
> >
> > feels like every module on CPAN providing an object system calls itself
> >
> > "modern". So by NOT doing so, Corinna would actually stand out more.
> >
> > I propose the term "effective" rather than "modern", barring that something
> >
> > better comes along. Also "concise" is good. You can use more than one.
> >
> > Frequently when I'm trying to figure out a name for something, including in my
> >
> > own language/format development, I explore thesaurus-dot-com which has been
> >
> > immensely helpful.
>
> I don't think "post-modern" is helpful either. I much prefer the term "counter culutural".
>
> That said, I'd like that as that we dig a little deeper into the fundamental support core needs to provide things like Corinna (formally known as Cor, let's not forget that). Rather than peeling the OOP "onion" back layer by layer, build it out from what exists now. Starting with what's needed to augment "bless", prototypes, and override.pm.
>
> I also don't find any weight to arguments like,
>
> - we're losing developers
> - no one is hiring
>
> It's about the application, <something that rhymes with cupid>.
>
> And if this is not an RFC, what the hell is it? Create some iterative RFCs by deconstructing what you think you need to get to this "not-RFC".
>
> Cheers,
>
> Brett
>
> > -- Darren Duncan
I meant overload.pm - sorry, was a placeholder and hit "send" a little too quickly.
Brett
??????? Original Message ???????
On Saturday, June 19th, 2021 at 8:41 PM, mah.kitteh via perl5-porters <perl5-porters@perl.org> wrote:
> ??????? Original Message ???????
>
> On Saturday, June 19th, 2021 at 3:44 PM, Darren Duncan darren@darrenduncan.net wrote:
>
> > On 2021-06-19 7:31 a.m., Ovid via perl5-porters wrote:
> >
> > > Tom wrote:
> > >
> > > /I'd claim that "modern" is not a useful term to be using in any
> > > documentation here - it's not descriptive, and the way it's used is more
> > > subjective than anything.
> > > /
> > >
> > >
> > > I've very annoyed by that comment because, damn it, it's spot on. I'll update
> > >
> > > the RFC when I have figured out a more appropriate phrasing. Or maybe Paul will.
> > >
> > > Dunno.
> >
> > I completely agree with this, but it hadn't occurred to me before.
> >
> > Using "modern" to describe something is so over-used its lost all meaning. It
> >
> > feels like every module on CPAN providing an object system calls itself
> >
> > "modern". So by NOT doing so, Corinna would actually stand out more.
> >
> > I propose the term "effective" rather than "modern", barring that something
> >
> > better comes along. Also "concise" is good. You can use more than one.
> >
> > Frequently when I'm trying to figure out a name for something, including in my
> >
> > own language/format development, I explore thesaurus-dot-com which has been
> >
> > immensely helpful.
>
> I don't think "post-modern" is helpful either. I much prefer the term "counter culutural".
>
> That said, I'd like that as that we dig a little deeper into the fundamental support core needs to provide things like Corinna (formally known as Cor, let's not forget that). Rather than peeling the OOP "onion" back layer by layer, build it out from what exists now. Starting with what's needed to augment "bless", prototypes, and override.pm.
>
> I also don't find any weight to arguments like,
>
> - we're losing developers
> - no one is hiring
>
> It's about the application, <something that rhymes with cupid>.
>
> And if this is not an RFC, what the hell is it? Create some iterative RFCs by deconstructing what you think you need to get to this "not-RFC".
>
> Cheers,
>
> Brett
>
> > -- Darren Duncan