Chad Perrin: SOB

1 August 2006

Example Class and Instantiation of Perl Closure-Object

Filed under: Cognition,Geek — apotheon @ 02:58

Many many moons ago, SOB (that’s where you are now) hosted a discussion of the idea of an object model based on lexical closures for the Perl programming language. Blame the sugar, or the fact I’ve been sleeping poorly, or whatever you like, but I’m going to make a half-baked attempt at actually demonstrating the creation of a class, with methods, plus instantiation of the closure-object and passing messages to it.

sub counter {
  my $int = shift;

  return sub {
    my $msg = shift;
    if ($msg eq 'inc') {
      print ++$int . "\\n";
    } elsif ($msg eq 'dec') {
      print --$int . "\\n";
    } else {
      $int = 0;

my $count = counter(0);


That should give output that looks something like this:

1 2 1 -1

It’s a new way of thinking about objects in Perl, sorta. At least, it looks new to me, since it’s not the “official” Perl object model, and nobody else seems to be doing it, but it achieves the necessary characteristics of a working object model.

This particular example covers three of the four OOP menu-items I listed in the above-referenced SOB post as being covered by a closure-object model in Perl: AYCDISAM, encapsulation, and protection. It doesn’t touch inheritance — something I’ll probably address at some later date.


  1. Yeah, that works. In some ways it’s similar to the object model inherent in the Win32 API, which is usually programmed in C. As with that model, the encapsulation is largely by convention (i.e., not enforced by the language/environment), and you have to supply the message dispatching mechanism (message loop and window procedures in the Win32 API). If coded properly, though, it can achieve a certain, should I say, elegance?

    Comment by SterlingCamden — 1 August 2006 @ 02:48

  2. That was the first thing that occurred to me when I moved from chapters about coderefs to chapters about OOP in (proto-)Intermediate Perl: that the guys who created the Perl object model really dropped the ball when they failed to realize that the mere existence of lexical scope and references in Perl provides an implicit object model that is, in fact, more elegant than the tacked-on mess that is used as Perl’s official object model.

    It’s possible that a language might be invented/discovered some day that enforces a closure-based object model, but Perl doesn’t enforce any object model at all. You can take it or leave it — and the steps one goes through to create objects of any sort can be altered, producing something other than an object, if you so desire. As such, Perl’s closure-based object model is as technically “enforced” by the language as its bless()-based object model, so far as I can tell.

    You’re right, of course, about the explicit message-dispatching behavior for the sort of closure-object (I’ll call it a clob, I think) that I demonstrated, but there are other ways to do it. I think I’ll create such a thing elsewhere soon. Hopefully I won’t disprove my own statement by discovering that what I have in mind doesn’t exactly work.

    Comment by apotheon — 1 August 2006 @ 03:59

  3. oh, but you know what i’ll say. the inheritance is the monkey wrench. go ahead. make a subclass that increments and decrements by two instead. or anything trivial like that.

    Comment by sosiouxme — 1 August 2006 @ 04:20

  4. For me, the real monkeywrench is that I don’t know OOP as well as I should before I start implementing all the complex features of a complete and feature-rich object model from pseudo-scratch. When I have what I consider to be a thoroughly competent understanding of what is expected of “inheritance” by OO programmers, I’ll see about implementing it by way of closures.

    Comment by apotheon — 1 August 2006 @ 07:33

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License