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
> 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