develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Inner classes/modules (was Re: RFC: Amores...)

Thread Previous | Thread Next
From:
Oodler 577 via perl5-porters
Date:
January 26, 2022 01:28
Subject:
Re: Inner classes/modules (was Re: RFC: Amores...)
Message ID:
YfCjkRQDT5lUTMKR@odin.sdf-eu.org
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About