However, I prefer using closures because I can define private and protected fields with ease.

I appreciate that you put some effort into drafting a tutorial-style meditation. However, in both this post and A quicker way to have protected and private fields?, you show a clear bias for closure-based objects over any other type. (You do realize that Objects with Private Variables was written in 2000, right?)

At the very least, for clarity, I think that you should retitle your post to something like "Closure objects with public, private, and protected fields".

Morever, I think that your piece would be much stronger if you explored several ways to do public, private and protected fields and articulated the pros and cons of each. Some people might reach different conclusions on whether the pros and cons lead to the same place.

For example, with a closure based object of the type you articulate, every private field access (from within __PACKAGE__) requires:

• Dereferencing the closure reference
• Calling the closure
• Two hash dereferences to get the access level
• Checking the access level and the caller
• Two more hash dereferences to get the value

Contrast that with an inside-out object:

package Duck::Secret;

use Class::InsideOut qw( private id register );

private secret => my %SECRET;

sub new { 
  my $self = register( bless \(my $s), shift );
  $SECRET{ id $self } = int( rand(100) );
  return $self;
}

sub guess_secret {
  my ($self, $guess) = @_;

  return $guess == $SECRET{ id $self };
}
[download]

Accessing that inside-out private field requires:

• Calling id (which is really Scalar::Util::refaddr)
• One hash lookup

So, in this example, if someone has lots of private fields and few (or no) protected fields, inside-out objects seem likely to have much better efficiency.

Adding protected accessors for inside-out objects is also easy:

# continuing previous code example

sub secret {
  my $self = shift;
  die "Secret is a protected field" if ! caller(0)->isa( __PACKAGE__ )
+;
  $SECRET{ id $self } = shift if @_;
  return $SECRET{ id $self };
}
[download]

That still has less overhead than a closure-based object.

So, maybe you'd like to consider a fuller treatement of the subject before declaring closure-based objects are the way to go.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.