The reason being is anyone, anywhere can do

my $x=bless {},"My::B";
[download]

Perls philosophy is "Id prefer you stay out of my living room because I ask you to, not because I have a shotgun." so you arent allowed a shotgun.

But i was thinking you could do something simple, a basic caller check to see if the calling sub originated in a module that @ISA "My::A". If it isnt then you could fail, if it is then everything is happy. Something like the following untested snippet

croak "Must be called from a My::A class or subclass."
      unless UNIVERSAL::isa(scalar caller(),"My::A");
[download]

<STONG>UPDATE
I think I sortof answered a question that Masem wasnt asking. :-) If the issue is regarding an aesthetic descion in how to indicate usage through form I would go (and have often done so) with having the 'private' class defined in the same file as the 'public', but at the end of file. Perhaps following some kind of comment that indicates that the contained classes are 'private' utility classes employed by the 'public' one.

Yves / DeMerphq
--
When to use Prototypes?
Advanced Sorting - GRT - Guttman Rosler Transform

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Howdy!

I'm with jeffa here...at least in the general case.

I do distinguish between "defining the class" and "diddling around in a class I've already gotten defined". In the latter, one might shift into the class to (re)define something or run some code in a different name space.

yours,
Michael

I'd probably go with My::A::B or even My::A::_B [ because a leading "_" is standard Perl "style" for "private, please do not touch" ].

If the code is very small, I'd put it all in one file. If not, I'd put it in a separate file. [ Though size is not the only issue. If My::A::B's code is easier to maintain by keeping it in the same file or vice versa, then that is a good thing to base your decision on. I like keeping it in the same file as an indication that the code is private to My::A, but would expect that consideration is often outweighed. ]

I'd also put it in a separate file if there is a possibility of using My::A without ever using My::A::B. In that case I'd be sure to require My::A::B only when I decide I need it and never use it.

Personally, I'd hate to see code in My::A::B's constructor that tries to enforce that only code from My::A may call it. [ I tried to come up with a short justification for my feelings here, but failed. There are a lot of aspects to it. Such protection usually can be gotten around so you are just making it a little harder. So why waste the cycles? Why add that extra code that can be a source of bugs? I've had to work around bugs in modules and finding code like this that makes such work-arounds harder just makes you want to shoot the module author for spending that time writing that code rather than spending time on real improvements so maybe you wouldn't have to be working around the problem... ]

[ Updated. ]

Indeed it seems that if you write code that ensures it is only run by the right parent, it defeats one of the main purposes of encapsulating it as a package. Code reuse is a good thing, not an evil to be guarded against.

I like it best when the visible file names match the public functionality of the Classes. Too many inner working files just ends up being a headache and doesn't tell people using your classes anything useful.

()-()                                                      ()-()
 \"/    DON'T   BLAME   ME,   I  VOTED   FOR    PACO!       \"/
  `                                                          ` 

I can think of two very good reasons to do this:

1. Private::B might develop into a hierarchy of its own, either as the root parent or as some child of an abstract class you don't know you need right now.
2. There may be some Private::C that, while not sharing an abstract parent with Private::B, might make sense to have in some Private:: hierarchy. For example, you might want to restrict that all Parser::'s can only be instantiated by a Reader::. There might not be an abstract parent (though I would think there should), but there definitely should be a separate hierarchy ...

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I agree with demerphq. Enforce restrictions through code, not organization.

Actually my point was that afaict in Perl enforcing such restrictions can only be done through code. But it was not that I think such a thing is a good idea.

Generally speaking I prefer that code doesnt restrict me in any ways that arent absolutely necessary. Just because someone cant think of a good reason why I would want to do X with their module doestn mean that I can think of one, and if I do im gunna be mighty unimpressed that they went out of their way to stop me, especially if there isnt a damn good reason why.

Yves / DeMerphq
--
When to use Prototypes?
Advanced Sorting - GRT - Guttman Rosler Transform

# NOTE: slightly modified code from the docs

package SomeClass;
use Attribute::Protected;

sub new { return bless {}, shift }

sub foo  : Public    { }
sub _bar : Private   { }
sub _baz : Protected { }

sub another {
      my $self = shift;
      $self->foo;               # OK
      $self->_bar;              # OK
      $self->_baz;              # OK
}

1;

package DerivedClass;
  @DerivedClass::ISA = qw(SomeClass);

sub yetanother {
      my $self = shift;
      $self->foo;               # OK
      $self->_bar;              # NG: private method
      $self->_baz;              # OK
}

1;

package main;

my $some = SomeClass->new;
   $some->foo;          # OK
   $some->_bar;         # NG: private method
   $some->_baz;         # NG: protected method
[download]

broquaint

package My::A;
...
package My::A::_B;
    sub TIESCALAR { return bless \(my $foo = $_[1]), $_[0] }
    sub FETCH { ${ $_[0] } }
    sub STORE { ${ $_[0] } = $_[1] }
package My::A;

sub method {
    my ($self, @foo) = @_;
    tie my $bar, 'My::A::_B', $foo[0];
    ...
}
...
[download]

++ vs lbh qrpbqrq guvf hfvat n ge va Crey :)
Nabgure bar vs lbh qvq fb jvgubhg ernqvat n znahny svefg.
-- vs lbh hfrq OFQ pnrfne ;)
    - Whreq

The package keyword is lexically scoped, so you can do

package My::A;
...
{
    package My::A::_B;
    sub TIESCALAR { return bless \(my $foo = $_[1]), $_[0] }
    sub FETCH { ${ $_[0] } }
    sub STORE { ${ $_[0] } = $_[1] }
}

sub method { # Is &My::A::method.
    my ($self, @foo) = @_;
    tie my $bar, 'My::A::_B', $foo[0];
    ...
}
...
[download]

Cheers,
-Anomo