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

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

Thread Previous | Thread Next
Darren Duncan
January 26, 2022 00:30
Inner classes/modules (was Re: RFC: Amores...)
Message ID:
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 

-- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About