OO paradigm and encapsulated instance variables in Perl5 [closed] - oop

Question

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I need a way to make really encapsulated variables in Perl, without using any frameworks like Moose, so that you can access the instance variables only through getters and setters. There should be private instance variables.
The subroutines respectively methods are not a problem, because you can define them so that they can be used just through an instance respectively a reference. But variables you can always access via the package name, like class-vars.
Is there any way to prevent that?

Answer 1

It sounds like you're trying to prevent people from accessing the instance variables other than through the accessors; is that right?
Perl is a language for polite people, and the way you stop programmers from doing things you don't want them to do is to ask them not to. Yes, there are hacks, and the most obvious one here would be to make each object a closure (here's an article about it from the Perl Journal) but there are almost always ways around them, so you won't be able to stop the determined impertinent hacker
One of Larry Wall's excellent attributions is this, which explains my point superbly
Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun

Answer 2

People tried to achieve this kind of thing with inside out objects. This presentation by David Golden explains it perfectly:
Inside-out objects first presented by Dutch Perl hacker Abigail in 2002
Spring 2002 – First mention at Amsterdam.pm,
June 28, 2002 – YAPC NA "Two alternative ways of doing OO"
July 1, 2002 – First mention on Perlmonks
Gained recent attention (notoriety?) as a recommended best practice with the publication of Damian Conway's Perl Best Practices
Despite their benefits, they bring significant complexity and are not universally welcomed
There are a number of modules that try to facilitate this type of programming.
I find them rather cumbersome, and they have since fallen out of favor.
You can also find them mentioned in perldoc perlobj:
In the past, the Perl community experimented with a technique called "inside-out objects". An inside-out object stores its data outside of the object's reference, indexed on a unique property of the object, such as its memory address, rather than in the object itself. This has the advantage of enforcing the encapsulation of object attributes, since their data is not stored in the object itself.
This technique was popular for a while (and was recommended in Damian Conway's Perl Best Practices), but never achieved universal adoption. The Object::InsideOut module on CPAN provides a comprehensive implementation of this technique, and you may see it or other inside-out modules in the wild.

Answer 3

To do really private variables you should use closures:
{
my $x;
sub get {
return $x;
}
sub set {
$x = shift;
}
}
set( 3 );
print get(); # prints 3
print $x; # ERROR
# Example with objects
package Class;
sub new {
bless {}, 'Class';
}
{
my $storage = {};
sub get {
$self = shift;
return $storage->{ "$self" };
}
sub set {
$self = shift;
$storage->{ "$self" } = shift;
}
}
package main;
print Class::x; #ERROR
$z = Class::new();
$z->set( 3 );
$y = Class::new();
$y->set( 5 );
print $y->get(); # 5
print $z->get(); # 3
The $x is local to the block. None except set and get may access it.
"$self" will be like "Class=HASH(0x1cf9160)". Because of each object has its own address in memory "$self" will never collision.
But actually you are not required to do so in other case that will be a stick in your wheel