Mailing List Archive

Inner classes/modules (was Re: RFC: Amores...)
On 2022-01-25 8:40 a.m., Ovid via perl5-porters wrote:
> It would be nice to see public and private inner modules which are hidden from
> the outside world. These would be analogous to the utility of inner classes.
> ...
> Eventually, package could be used for older namespace declarations, while
> modules would be first-class and not necessarily exposed via the namespace
> mechanism unless they were public (or perhaps not even then).

I wanted to address this tangent to both Corinna and Amores etc.

I feel that it is important for class names and module names etc to always have
publicly addressable names in the same manner as classic Perl package names,
even when they are declared as "private" within other classes or modules.

This is especially true with classes that can be instantiated as objects.

At the very least this is important to properly support reliable
serialization/export/dump and deserialization/import of objects as their
structure or fields might be defined in terms of such "inner" classes even if
those classes are "inner" because they aren't intended to be used apart from
what they are nested in.

Likewise it is important for keeping debugging easier.

Likewise it would probably make implementation behind the scenes simpler.

So declaring a class/module ":private" should simply block normal-style
invocation of it from particular contexts but it should not prevent the
awareness of the existence of the class/module from anywhere. Regular
reflection/introspection capabilities such as they exist should still know about
these.

-- Darren Duncan
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
Apologies for me not tracking this very well.

What is "Amores" and how does it relate to "Corinna" and, in general,
Perl OOP?

Thanks,
Brett

* Darren Duncan <darren@darrenduncan.net> [2022-01-25 16:30:06 -0800]:

> On 2022-01-25 8:40 a.m., Ovid via perl5-porters wrote:
> > It would be nice to see public and private inner modules which are
> > hidden from the outside world. These would be analogous to the utility
> > of inner classes.
> > ...
> > Eventually, package?could be used for older namespace declarations, while
> > modules would be first-class and not necessarily exposed via the
> > namespace mechanism unless they were public (or perhaps not even then).
>
> I wanted to address this tangent to both Corinna and Amores etc.
>
> I feel that it is important for class names and module names etc to always
> have publicly addressable names in the same manner as classic Perl package
> names, even when they are declared as "private" within other classes or
> modules.
>
> This is especially true with classes that can be instantiated as objects.
>
> At the very least this is important to properly support reliable
> serialization/export/dump and deserialization/import of objects as their
> structure or fields might be defined in terms of such "inner" classes even
> if those classes are "inner" because they aren't intended to be used apart
> from what they are nested in.
>
> Likewise it is important for keeping debugging easier.
>
> Likewise it would probably make implementation behind the scenes simpler.
>
> So declaring a class/module ":private" should simply block normal-style
> invocation of it from particular contexts but it should not prevent the
> awareness of the existence of the class/module from anywhere. Regular
> reflection/introspection capabilities such as they exist should still know
> about these.
>
> -- Darren Duncan

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
On 2022-01-25 5:27 p.m., Oodler 577 via perl5-porters wrote:
> Apologies for me not tracking this very well.
>
> What is "Amores" and how does it relate to "Corinna" and, in general,
> Perl OOP?

All you have to do is look at the p5p posts from 8 hours prior to my post that
you responded to. Ovid made a post about Amores which is a name to refer to his
proposal about adding a "module" keyword to Perl for exportable subs, and it is
a counterpart to Corinna which is about OOP. You don't have to dig much, its
all from earlier today. -- Darren Duncan
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
* Darren Duncan <darren@darrenduncan.net> [2022-01-25 18:09:31 -0800]:

> On 2022-01-25 5:27 p.m., Oodler 577 via perl5-porters wrote:
> > Apologies for me not tracking this very well.
> >
> > What is "Amores" and how does it relate to "Corinna" and, in general,
> > Perl OOP?
>
> All you have to do is look at the p5p posts from 8 hours prior to my post
> that you responded to. Ovid made a post about Amores which is a name to
> refer to his proposal about adding a "module" keyword to Perl for exportable
> subs, and it is a counterpart to Corinna which is about OOP. You don't have
> to dig much, its all from earlier today. -- Darren Duncan

I saw that. I guess I picked the wrong day to stop sniffing glue.

So do I add "Amores" to the "Cor/Corinna/Perl7" bucket or it, like,
a new thing?

Can't it just be a normal titled pre-RFC? Or are we all expected to
now add some weird codename reference to proposals that should just
otherwise we titled what they are?

Oh, here we go WP to the rescue:

Amores is Ovid's first completed book
of poetry, written in elegiac couplets.
It was first published in 16 BC in five
books, but Ovid, by his own account,
later edited it down into the three-book
edition that survives today

Okay now we're on to somthing. Still doesn't explain how this relates
to some strategic plan to zip up both trad Perl and POOP into one
harmonious poop utopia. Care to explain what the overall play is here?
This may also hopefully help explain to me what "non-OOP" C<module> is
going to actually do for the regular perl stiff.

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
* Oodler 577 via perl5-porters <perl5-porters@perl.org> [2022-01-26 05:35:48 +0000]:

> * Darren Duncan <darren@darrenduncan.net> [2022-01-25 18:09:31 -0800]:
>
> > On 2022-01-25 5:27 p.m., Oodler 577 via perl5-porters wrote:
> > > Apologies for me not tracking this very well.
> > >
> > > What is "Amores" and how does it relate to "Corinna" and, in general,
> > > Perl OOP?
> >
> > All you have to do is look at the p5p posts from 8 hours prior to my post
> > that you responded to. Ovid made a post about Amores which is a name to
> > refer to his proposal about adding a "module" keyword to Perl for exportable
> > subs, and it is a counterpart to Corinna which is about OOP. You don't have
> > to dig much, its all from earlier today. -- Darren Duncan
>
> I saw that. I guess I picked the wrong day to stop sniffing glue.
>
> So do I add "Amores" to the "Cor/Corinna/Perl7" bucket or it, like,
> a new thing?
>
> Can't it just be a normal titled pre-RFC? Or are we all expected to
> now add some weird codename reference to proposals that should just
> otherwise we titled what they are?
>
> Oh, here we go WP to the rescue:
>
> Amores is Ovid's first completed book
> of poetry, written in elegiac couplets.
> It was first published in 16 BC in five
> books, but Ovid, by his own account,
> later edited it down into the three-book
> edition that survives today

I should have kept reading wikipedia,

The Amores is a poetic first person account
of the poetic persona's love affair with an
unattainable higher class girl, Corinna. It
is not always clear if the author is writing
about Corinna or a generic puella. Ovid
does not assume a single woman as a subject
of a chronical obsession of the persona of
lover. The plot is linear, with a few artistic
digressions such as an elegy on the death of
Tibullus.

So, can we just how this ultimately translates to a strategy, or
are we expected to believe that this is just some playfulness?

I am not suggesting anything bad, but it might help with whatever
the "plan" is to just get on with it and not waste anyone's time
guessing how this party ends. I'm particularly interested in
what other references are coming down the pike.

So we got Cor (heart in Latin) that became Corinna (said "higher
class girl). Then Amores, defined above. I'm just super curious
now. :-)

Cheers,
Brett

>
> Okay now we're on to somthing. Still doesn't explain how this relates
> to some strategic plan to zip up both trad Perl and POOP into one
> harmonious poop utopia. Care to explain what the overall play is here?
> This may also hopefully help explain to me what "non-OOP" C<module> is
> going to actually do for the regular perl stiff.
>
> Cheers,
> Brett
>
> --
> --
> oodler@cpan.org
> oodler577@sdf-eu.org
> SDF-EU Public Access UNIX System - http://sdfeu.org
> irc.perl.org #openmp #pdl #native

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
On 2022-01-25 9:48 p.m., Oodler 577 via perl5-porters wrote:
>> I saw that. I guess I picked the wrong day to stop sniffing glue.
>>
>> So do I add "Amores" to the "Cor/Corinna/Perl7" bucket or it, like,
>> a new thing?

Brett, can you please ask your questions in response to the original thread
"RFC: Amores. Introducing a `module` keyword"? This current one I started is
meant to be about the "inner" classes/modules specifically, not general Amores
stuff. Or comment on the Github issue for Amores which is in the process of
being created. Thank you. -- Darren Duncan
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
On Tue, Jan 25, 2022 at 11:48 PM Oodler 577 via perl5-porters
<perl5-porters@perl.org> wrote:

> I am not suggesting anything bad, but it might help with whatever
> the "plan" is to just get on with it and not waste anyone's time
> guessing how this party ends. I'm particularly interested in
> what other references are coming down the pike.

The next step would the racy Ars Amatoria (Art of Love), then exile
for offending the emperor (possibly because some of those love poems
were a bit too racy), followed by the composition of the Metamorphoses
(Changes), where almost anything can be transformed into anything else
at the whim of the gods but in ways that provide interesting origin
stories for how things got to be the way they are. I should warn you
that the Metamorphoses is a lot longer than any of the earlier work
:-).
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
> The next step would the racy Ars Amatoria (Art of Love), then exile
> for offending the emperor (possibly because some of those love poems
> were a bit too racy), 

Strictly speaking, Ovid was relegated to the frontier city of Tomis, not exiled. They're almost the same, but with relegation, you retain your citizenship and property (though on his trip to Tomis, his servants stole everything).

> followed by the composition of the Metamorphoses
> (Changes), where almost anything can be transformed into anything else

I'm absolutely shooting for Metamorphoses. Background of our company, over the course of many years:

1. We were getting plenty of requests for new Perl development.
2. We started getting fewer contracts.
3. With the COVID economy, we're getting multiple "how do we get rid of Perl?" requests.

In speaking with other consultants, their specifics differ, but not too much. And I suspect that we're probably getting more people reaching out to us than others due to my name.

Since https//allroundtheworld.fr/ does more than just Perl, it was natural for companies to contact us about transitioning. We're really good at project management. 

But this is the endgame for Perl. I do not wish to go gently into that dark night. Thus, it's time to change the game.

I've tried different approaches, some of which are private and won't be discussed here. My primary obstacles have been:

1. I can't hack on Perl internals (my C is too rusty)
2. Even if I could hack on Perl internals, I have too much paying work to do
3. Many others I've spoken to don't have the time/energy/desire to continue

When we started getting fewer contracts, a common issue in speaking to potential clients was "we're waiting for Perl 6 for an upgrade path." No amount of explaining *ever* overcame this objection.

So there was no Perl 6.

Perl 7 was announced and there was no Perl 7.

Thus, companies again see no upgrade path and we are getting more of the "delete Perl" requests. Many of us are older and I've seen more than one older Perl hacker saying, "I can ride this out to retirement." I completely respect that. Younger Perl developers are leaving for Python or other languages. I can respect that, too.

Maybe I should choose one of those options, but instead, I choose to make a last stand.

I want Perl 7 to come out.

First, let's talk about goals. What do we want to accomplish?

If we have a goal, we also need to explain why we want this goal.

We then plan a strategy to achieve that goal.

We then use tactical responses (RFCs) to implement our strategy.

But I don't know what our strategy is, though I assume our goal is the survival of the Perl language. We're in the endgame and we don't know what game we're playing.

Deprecating a little-used feature is nice for Perl, but doesn't add much value for business. `say` was a beautiful feature for developers, but doesn't add much value to business. Fixing obscure bugs is important, buy doesn't add much value for business.

These are clearly defined tactical responses to an undefined strategy to support a somewhat defined goal.

Both the Perl 6 and Perl 7 initiatives were strategies to achieve the goal of survival of a language we love (or at least are comfortable with).

I don't see any strategy now.

So, fuck it. I want Metamorphosis. I've tried (and failed) with various approaches. I can admit my failures, even if some of them were private. Those failures were largely due, quite frankly, to me not admitting my limitations. So if my goal is the survival of the Perl language, I need a new strategy to support my goal of Perl's survival. My current strategy involves:

1. Design features in groups that are thought out together.
2. Limit new feature scopes to avoid the issue of simply having `use v7` in legacy code break things.
3. Adopt a more uniform KIM syntax (keyword, identifier, modifier).
4. Address a definition of done for feature groups necessary to say "this is Perl 7."

New *holistic* features. not tweaks. Create a backwards-compatible vision of the future. We don't have the popularity to support a Python 2/3 split.

Stop playing the game that we're playing now because the definition of insanity is ... well, you know the quote.

Change the game. Throw the Hail Mary pass. 

<neo>I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin</neo>

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl
Re: Inner classes/modules (was Re: RFC: Amores...) [ In reply to ]
On Wednesday, 26 January 2022, 21:03:04 CET, Ovid via perl5-porters <perl5-porters@perl.org> wrote:

(not Perl, feel free to ignore)

> > The next step would the racy Ars Amatoria (Art of Love), then exile
> > for offending the emperor (possibly because some of those love poems
> > were a bit too racy), 

Historical note: many historians don't believe that Ovid was exiled because his poems were too racy. There were plenty of other racy, and popular, writers at that time. Instead, he was relegated (banished, if you prefer, not exiled) because Ovid wrote his banishment was due to "carmen et error" (poetry and error).

This is complicated because Ovid often employed a rhetorical technique, hendiadys, whereby two different ideas are joined by "and" ("et", in Latin) to express a single idea. Except in this case, these ideas may be mutually exclusive. Clearly he can talk about his poetry but he would not talk about his error. Thus, he might be talking about different things whereby Augustus used his poetry as an excuse, but the real reason he was relegated was due to the error Ovid can't talk about.

It was long after Ars Amatoria was published before Ovid was relegated to Tomis, so his poetry, though a cited reason, may not be the cause of his banishment. (I'm pretty sure it wasn't the cause).

Ovid was relegated, not exiled or executed. If Ovid saw (or participated) in something treasonous, execution or exile would likely have been supported. So I'm of the opinion that he likely saw something politically damaging for Augustus, but probably wasn't *legally* serious. Thus, Augustus couldn't execute Ovid, but he could move that piece off the board.

If it's not Ovid's poetry, what was his error? Clearly he can talk about his poetry, but he apparently could not not (or would not) talk about his error. Since he spent much of the remainder of his time in relegation petitioning Augustus to let him return to Rome, it's speculated that what happened is that Ovid saw, or knew, about something that he kept quiet about and that's why he was relegated.

Was it a plot to overthrow the emperor (treason: I don't think so)? Did Ovid witness a relative of Augustus engaging in immoral behavior in defiance of Augustus' attempts to introduce moral reform? Did Ovid discover something compromising about the emperor or someone close to him?

We don't know what happened, but it probably wasn't Ovid's poetry.

Best,
Ovid (not the poet)
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl