Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

looking towards learning OOP

by spx2 (Deacon)
on Sep 12, 2008 at 09:39 UTC ( #710860=perlquestion: print w/replies, xml ) Need Help??
spx2 has asked for the wisdom of the Perl Monks concerning the following question:


Recently I have thought of seriously taking on learning OOP in perl.
Apart from the fact that I know little of the mechanisms which lie behind use,require,bless
(altough I have read about them on several occasions I have not used them all that often)
I would like to adopt a framework.
The obvious choices for me seem to be the following:
1)reading Damian Conway - Object Oriented Perl(which however could be time wasted
as it dates back to 2000 so could be seriously out-of-date,please correct me if I'm wrong)
2)reading more about Moose(which however seriously lacks some nicely binded documentation,
it just has presentations,articles,perldocs and it is a hard-to-follow learning process if
it's adopted)
3)reading more on Spiffy(which suffers from bad critique from cpan reviewers,but apart from that
seems to be nice)
I should mention that I have previously played with Moose and found it interesting.
So,I am seeking your wisdom on choosing on knowing what other alternatives I have for 1),2),3)
and also what you think will work out best.
Also my problem is that there are many such modules on cpan but none really offers any reliability,for me at least,in the
sense that they don't have sufficient documentation and I can't see someone saying:
"This is the object-system we have settled on and this one should be used because we have decided to so and we include it in some standard"

Best regards,

Replies are listed 'Best First'.
Re: looking towards learning OOP
by moritz (Cardinal) on Sep 12, 2008 at 09:56 UTC
    I think that "learning OOP in Perl" should be seen as two steps - first "learn object oriented programming", then "learn how to do it in perl".

    For the first step I can strongly recommend Object Oriented Software Construction by Bertrand Meyer. It uses Eiffel for all its examples (which is a very nice language, but totally different from perl), but don't let that deter you. Nearly all ideas in object orientation are language independent. It's a great book, but rather technical.

    Once you know how object orientation works, it's not hard to learn from the perl documentation. I learned it from perlboot and perltoot. I'm also sure that once you have a firm grasp of OO, you will find the Moose documentation sufficient.

    As to TheDamian's book - I haven't read it, so I can't really comment. But from reading his book "Perl Best Practices" I can say that he write great books, but his module recommendations are bit weird sometimes.

      As to TheDamian's book - I haven't read it, so I can't really comment. But from reading his book "Perl Best Practices" I can say that he write great books, but his module recommendations are bit weird sometimes.

      Yes, and apropos to the subject at hand, in "Best Practices" he recommends his own Class::Std to do inside-out objects, when the consensus seems to be that Object::InsideOut or Class::InsideOut are better choices.

      Still, if you're getting started with OOP, you can do worse than read "Object-Oriented Design" and "Best Practices".

Re: looking towards learning OOP
by pjf (Curate) on Sep 12, 2008 at 13:45 UTC

    Other posters have recommended learning OO design and theory before leaping into doing it in Perl. I'm in agreement with them, so I won't repeat their points here. Instead I'll focus on how leap into Perl once you get there.

    Damian's OOP book is good, but it reflects the state of OOP eight years ago, and things have changed quite a bit since then. All the things about pseudo-hashes are right out; they've been officially deprecated and removed from the language in more recent releases of perl.

    If you want a more up-to-date text, I'd recommend Perl Training Australia's Object Oriented Perl course notes (there's a downlink link to the pdf near the top), which also contain references into Damian's book if you've got it. You may also wish to consider "Perl Best Practices", which contains a detailed chapter on OOP, and does cover many recent advancements.

    Disclaimer: I own half of Perl Training Australia (PTA), and my name is on the front of the OOP notes, so I may be biased.

    However I feel both PBP and my own OOP text both cover OOP as it was a couple of years back. OOP is one of those things where I feel there are too many ways to do things. Trying to do it without a framework is a lot of work, and becomes much harder when one appreciates all the things that can go wrong with inheritance.

    These days, I've been recommending Moose. It's a complete framework, it's been tested in some very big enterprise projects, it's going into the Google Perl AppEngine framework, it has a great community, and it has some of the smartest people I've ever met working on it. The only reason it's not in PTA's OOP notes is because I haven't had time to write about it.

    If you are learning Moose, I'd recommend hopping on the #moose channel on It tends to be very active, and very helpful, and you'll usually find all the core developers there. If you need a hand, it's a great place to ask.

    I've not heard of Spiffy before, so I can't comment on it one way or the other.

    All the best,

Re: looking towards learning OOP
by broomduster (Priest) on Sep 12, 2008 at 09:46 UTC
Re: looking towards learning OOP
by skiphoppy (Acolyte) on Sep 12, 2008 at 16:20 UTC


    From your post I understand you to mean that you've never done OO programming before, and you are wanting to learn it within Perl, not that you already understand OO and simply want to learn how to do it in Perl.

    This is exactly the same boat I was in around 9 years ago as a budding Perl programmer. I had never touched OO; I thought it was some useless buzzword. I'd seen it explained slightly in some introductory CS textbooks, but never in a way that made the use apparent. :)

    Perl is where I learned OO, and that has been the right place to do it. I completely disagree with those who said go learn your OO concepts elsewhere and then come learn how to do it in Perl. The authors of Perl's OO documentation are some of the world's best programmers. If you learn OO here, you will learn it as well as or better than you will learn it anywhere else.

    This was exactly the case for me. Within two years of learning OO through Perl, I was designing a team project and school and everyone agreed my OO design work was spectacular, even though they had far more OO experience than me. I've received similar such validation for my OO understanding ever since, in undergraduate and graduate work, as well as in my professional career. I am today (sadly) a Java programmer (though still a Perl programmer at heart), and much of my work consists of fixing up things people have done earlier, improving the OO considerably for real, tangible benefits in maintainability, added features, and bug fixes.

    Sorry; I hope it doesn't sound like I'm tooting my own horn. I'm just another Perl programmer. :) I'm just saying that if you learn OOP in the Perl world, you will not be at any disadvantage under other languages, and in fact you may very well find yourself at an advantage.

    Here's a path I'd recommend; it looks similar to the path I took:

    • Learn to use one or more object-oriented modules. There's no better way to wrap your head around OO than simply iusing/i somebody else's classes and objects. Trying to learn to create your own first is all wrong. The module I used was, but today the recommendation is to not use that module in an OO fashion. :) I believe the module I would recommend for you is DBI. (And a backend of your choice.) If you already know DBI or at least one other object-oriented module, you already have a substantial leg up!
    • Now go read perlboot and perltoot from the Perl documentation. I think in my day all I had was perltoot. :) Actually I made it a point to sit down every day after lunch and read through an entire perl manpage, after about a year's Perl experience. There's a lot more to read nowadays. :) I wasn't doing this to learn OO; that was one of the side-benefits. "perldoc perl" gave a suggested reading order back then that has been immensely fleshed out since.
    • After perlboot/perltoot and some playing around (probably including writing a class or two for real tasks), you can spend some time with the Damian Conway book, though this may not be necessary at that point. I have that book and have never finished it. You most likely don't need to know all the special non-standard ways of doing OO, like blessing things that aren't hashes, or making your classes be inside out or upside down or whatever else is in vogue these days. Learning all those things is good, but they are the 80% of the effort behind the last 20% of the work. So don't get bogged down this year feeling like you have to read everything professor Conway has to say; save some for when you are a wizard doing advanced experiments.
    • After this, I would say, go adopt Moose and learn it. I have to say Moose has only recently caught my attention, and being a Java programmer by trade I haven't had time to build anything real with it, yet. But it really looks to me like The Way To Go, bringing in a lot of wonderful things to Perl's OO. My next object-oriented Perl code WILL be a subclass of Moose.
    • After that you will be a wizard. Do what you want. Learn all the funky stuff. :)

      This is the best advice in this thread.

      The easiest way to start is with "classical" blessed hashes. You can do a lot with them. The mechanisms are relatively clear.

      I'd suggest reading perlboot and perltut. If you want more detailed discussion of the basics, get Conway's OOP.

      Once you grok the classical method, explore. Either go straight to Moose (if you are primarily pragmatic in your thinking) or read the rest of OOP and explore a bit. Learn about AUTOLOAD to build methods automatically, blessing typeglobs, and all other manner of strange things.

      TGI says moo

Re: looking towards learning OOP
by johngg (Abbot) on Sep 12, 2008 at 09:50 UTC
    I don't think option one would be wasted time. The book is very well written and is witty which, for me, always helps to hold the attention. It explains concepts clearly and with examples that one can relate to. Although new techniques have come along since the book was published, the basic concepts have not changed and are still relevant.



      Conway's "Object-Oriented Perl" is indeed a pretty good book, and doesn't deserve to be dismissed as dated. It was written before the current fad for inside-out objects, but if you're interested in understanding the more traditional hashref-based objects, it's a good place to start.

      A few caveats:

      • It praises pseudo-hashes, a feature that was immediately regarded as a mistake and was quickly deprecated and removed.
      • Throughout, it uses an example that's arguably better suited toward a relational database approach -- it may explain object design very well, but it's not necessarily an example of good design.

Re: looking towards learning OOP
by dHarry (Abbot) on Sep 12, 2008 at 11:51 UTC

    I am with brother moritz, i.e. the two step approach. Once you have mastered the OO concepts it can serve you well in any programming environment. OO is a philosophy and program languages have various degrees of supporting it, ranging from not-at-all to fully OO.

    You can for example even write OO programs in COBOL (with a lot of discipline I admit) but other language have specific constructs which make it a lot easier. I liked Object-Oriented Design as a general book on OO. As a warning: OO can have a steep learning curve. The more experience you have with non-OO languages the longer it usually takes to write decent OO programs.

    Specific for Perl you can look in the Perl Cookbook, chapter 13. “Classes, Objects, and Ties”, Programming Perl, Chapter 5 “Packages, Modules, and Object Classes” and Advanced Perl Programming, chapter 7. “Object-Oriented Programming” + chapter 8. “Object Orientation: The Next Few Steps”. There is lots of stuff in the Monastery and on Internet in general, just Google for it. The suggestions above are also well worth considering.


Re: looking towards learning OOP
by perrin (Chancellor) on Sep 12, 2008 at 11:58 UTC
    The docs that come with Perl are pretty good. You might want to give them a shot before you go looking for something else.
Re: looking towards learning OOP
by whakka (Hermit) on Sep 12, 2008 at 19:37 UTC

    Thanks for asking this question as I'm (almost) in the same boat. I have some training in Java but rely on Perl for most of what I do. I want to do a re-write of a Perl project from procedural to OO that's becoming increasingly unwieldy and difficult to maintain and expand. Before I start though I've been trying to understand the best way to go about learning OO in Perl and one that I think makes sense.

    To me, native Perl OO (blessing an anonymous hash ref) doesn't make sense. You get no encapsulation (and hence potential namespace conflicts) and get none of the benefits of strict and warn since you're storing data according to keys, not hard-coded variables. This is crazy, completely insane! I desperate want strict and warn when I'm trying to make more wieldy code out of my large data structures, and especially when I'm trying to learn how to do it.

    So I started investigating inside-out objects, a clever hack on top of Perl's native OO that encapsulates instance data with compile-time checking, just the way I want it. However I got a number of suggestions before settling on Class::InsideOut as the best potential solution (but not without significant reservation). Then I got suggested Moose as a nice OO framework. Moose on the surface looks good but to me it's a huge black box and not part of the standard distro, so my code becomes that much less portable (which is a goal).

    So you guess I could say I'm confounded by the TMTOWTDI nature of it all - with objects, seriously, I only need one paradigm that looks and feels like Perl. At this point I'm ready to throw up my hands and just use the native Perl method to see if it's worth all the fuss to avoid it, although I know if anything should go awry I may regret my decision. I look forward to weighing all the suggestions in this thread.

      my problem with Moose is that its documentation becomes obsolete
      as time passes by and it is spread(presentations,articles,cookbooks,cpan docs) all over the internet.
      noone seems to understand that for it to be attractive for developers
      it needs to have nicely binded documentation in one place and one place only.
      if I go to #moose people are nice, but it is not nice for me to come knocking on
      their door each time I hit a bump in the road just because noone took the trouble
      to nicely bind and write a good documentation for the project.
      and if documentation isn't enough or well written or any at all ,
      they suggest to read the source code,but that would be an effort for my side
      so big,that it would mean not only I am trying to learn Moose but also it's internals,
      the latter of which was not my intention at all.

      as a sidenote:
      if I want to learn c++ it doesn't require me to understand the internals and/or read it's
      source code(altough on some occasions it is useful)I just need to read the description of what each class does,it's methods,some
      examples and I can start using it
        Yes, there's presentations and tutorials spread all over the Internet, but the official, always up-to-date, documentation is on the CPAN here. In that documentation are a set of tutorials called the Cookbook.

        There isn't much to learn about basic Moose:

        package Shape; use Moose; has color => ( # an attribute called 'color' is => 'rw', # creates an accessor for the color isa => 'Str', # and it's a string ); package Circle; use Moose; extends 'Shape'; # Circle isa Shape has radius => ( is => 'rw', isa => 'Num' ); sub area { my $self = shift; return 3.141 * $self->radius ** 2 } package Rectangle; use Moose; extends 'Shape'; # Rectangle isa Shape has width => ( is => 'rw', isa => 'Num' ); has height => ( is => 'rw', isa => 'Num' ); sub area { my $self = shift; return $self->width * $self->height; } package main; use strict; use warnings; my $r = Rectangle->new(height => 2, width => 2.5, color => 'green'); my $c = Circle->new(radius => .5, color => 'yellow'); printf "My %s is %s and has an area of %0.2f\n", ref $_, $_->color, $_ +->area for $r, $c; $c->radius(1); # The circle is now twice the size printf "My new Circle is %s and has an area of %0.2f\n", $c->color, $c +->area

        Moose just makes it so quick and easy. Of course, Moose can do so much more, but that's what the documentation is for.

        (Yes. I know. Roles would have been better)

        Unless I state otherwise, all my code runs with strict and warnings

        About not wanting to "bother" #moose with your beginner's issues:

        Look at it the other way around. You're a beginner and trying to learn things. You read the documentation and there's something you don't get. You ask #moose. You get a good answer. Here's what you have to do to make #moosee helping you benefit Moose: Apply small fixes to the documentation as you go along!

        I think it's Matt Trout who's been saying over and over again that as an expert, you can't reasonably write good beginner's documentation because you have no idea what the hell's so difficult about it. Conversely, if there's going to be a beginner friendly text, beginners have to be involved in the making.

        Best regards,

        my problem with Moose is that its documentation becomes obsolete as time passes by and it is spread(presentations,articles,cookbooks,cpan docs) all over the internet

        I disagree, if it is not in the CPAN Moose docs, then it is here, and if it not in either of those place then I don't know about it and so can't link to it. Also I am not sure how the spread and growth of information on something causes the core docs to become obsolete? If anything the core docs should always be thought of as definitive.

        noone seems to understand that for it to be attractive for developers it needs to have nicely binded documentation in one place and one place only.

        Actually, we understand that all to well, but it is a matter of people finding time. Personally i think the recently re-organized cookbooks as well as the new Moose::Intro and Moose::Unsweetened docs go a long way towards filling some of the needs you describe.

        Of course documentation always needs work, both keeping it up to date and expanding on things which are not covered as well as they could be. You simply have to stop by #moose or ask on and we will be happy to give you a commit bit and you can start fixing it right away.

        as a sidenote: if I want to learn c++ it doesn't require me to understand the internals and/or read it's source code(altough on some occasions it is useful)I just need to read the description of what each class does,it's methods,some examples and I can start using it

        This is not in any way a fair comparison.

        C++ is over 20 years old (1985 or so) has the support of several major corporations (AT&T, IBM, Microsoft, etc), is an ANSI and ISO standard and got millions of dollars pumped into training, books and other forms of documentation over the last 15-20 years.

        Moose is just 2 1/2 years old and is a volunteer driven open source project with absolutely no funding, grants or anything of the like.

Re: looking towards learning OOP
by steve (Deacon) on Sep 12, 2008 at 14:28 UTC
    Having learned OOP first (and then Perl), I would agree with moritz et al. It worked for me. Learning the principles of OOP in general will serve you well. Something else that helped me was to dig through the code of some well written Perl OO examples. Perlmonks is a great place for recommendations of such.
Re: looking towards learning OOP
by jethro (Monsignor) on Sep 12, 2008 at 15:07 UTC

    " and I can't see someone saying: "This is the object-system we have settled on and this one should be used because we have decided to so and we include it in some standard" "

    But the good news is, whatever object system you would like to use, there probably is already a perl module for it

    Anyway, for a beginner the object system he uses is unimportant IMHO. The different object systems are in essence syntactic sugar. What you want to learn are the concepts of oo, not the syntax. So find a good oo book and either go with the system your book uses or make the effort to translate to whatever system you want to use.

Re: looking towards learning OOP
by sunshine_august (Scribe) on Sep 12, 2008 at 16:26 UTC

    check <intermediate perl> (writed by Randal L. Schwartz, brian d foy, Tom Phoenix) the chapter9-10 explain the require, use etc function, and chapter11-13 explain programming perl in OO style step by step thru a simple example.
    whatever, I did learnt a lot about OO programming in perl with it;)

Re: looking towards learning OOP
by SouthFulcrum (Sexton) on Sep 12, 2008 at 16:44 UTC
Re: looking towards learning OOP
by Zen (Deacon) on Sep 12, 2008 at 15:50 UTC
    I guess I'm the only one in disagreement. I'd rather step by step labs to creating a simple OO program and then get into theory. Flowery prose or banal diatribes aren't as good as hands on for some people's learning style.
      Bravo! "The journey is made long and tedious by precepts, short and efficient by examples" is as true today as it was two thousand years ago.
Re: looking towards learning OOP
by blahblah (Friar) on Sep 13, 2008 at 14:01 UTC
    I personally struggled for a long time to grasp OOP, and then OOP in Perl. About two years. I don't have any formal training in computer science, but knew it was an important concept to try to learn. I read all the perldocs. I read the Conway book. But I just needed something with short clear examples that did not contain the distracting "humor" that seems to be part of the culture around Perl.

    In the end I finally found The One that did it for me: Tutorial: Introduction to Object-Oriented Programming. Its in the Tutorial section here, which was mentioned by the first poster - but there are 21 others. This one is wonderfully clear and the examples are very clean and straight forward. The ensuing conversation elucidates the pitfalls in the presented material beautifully and concisely. As a bonus, a lengthy portion of the conversation also covers inside-out objects in Perl.

    Using what was written there I wrote my first completely OOP database driven web application... and I loved the result. There was a lot more code to write, but the maintainability trade-off was very worthwhile. My complements to jreades!

    Robert Browning on being asked what some line in one of his poems meant said
    'When I wrote it only God and Robert Browning knew. Now only God knows.'
      Key drawbacks- the amount of code to write and hoping devs beyond you understand the design- are often missed points.
Re: looking towards learning OOP
by zentara (Archbishop) on Sep 12, 2008 at 14:47 UTC
    I'm no OOP expert, but one piece of advice I can give, is learn to write your scripts storing everything in a hash. That way, you can write a functional script as a prototype, and get it working, then when you want to go to OO, just containerize it, and bless the hash as $self.

    I'm not really a human, but I play one on earth Remember How Lucky You Are
      That's the sad part about OO in the greater Perl community. Many people think that once you blessed that hash, you are doing OO. But OO is not about hashes, and blessing is only a necessary condition.
        Just to take the opposite side of this argument: it is not at all clear to me that the doctrine of "Object-Oriented Design" has anything going for it -- this isn't the sort of thing anyone ever takes the trouble to do studies of, so instead we're all left shouting our anecdotes and personal impressions at each other. Notably, what exactly OO Design is is somewhat up for grabs, and has certainly changed over the years (any failures in OO designs, you see, can never be the fault of OO design itself, but instead must be the result of a poor implementation... and so we have ancilliary doctrines accumulating around the original doctrine, e.g. "design patterns").

        One could make the case that using objects in perl is a little less onerous than in a more fundamentally object-oriented language, because you can be a little sloppier about it and let the abstractions leak when they need to.

        My own take would be that pursuing some grand understanding of the fundamental principles of objects before you proceed with actually using them would be totally crazy: you'll never be done with it, and never get down to the concrete-level to see if using objects actually does anything for you. Most likely you'll need to pursue both levels at the same time, and a good way to start may very well be to think about object classes as a collection of routines that share data via a blessed hashref.

        Some of my own suggestions (for what they're worth, and I'm not sure how much they are):

        • I still favor hashref-based objects over "insideout" objects (it's very convenient to be able to dump the hashref when you're debugging, and in general they seem more perlish to me);
        • I currently use the very simple Class::Base to base my objects on, though I usually add my own AUTOLOAD section to generate accessors -- manually created accessors aren't bad to start with however, particularly if you have some sort of editor macros to create them.
        • I strongly favor aggregation (object fields that contain other objects) over inheritance -- but if you find yourself adding a field named "type" to your object classes, it's a sign you might need to be using inheritance instead.
        • Instead of working from theory on down, you might think about examples of things you've seen work: it's better to hold DBI/DBD in mind than jargon about "the factory pattern" or some such.
        • Remember, the name of the game is to split large tasks into small that it's easier to wrap your brain around. If you've got an elaborate framework of classes that needs to be understood it may be doing more harm than good.

Re: looking towards learning OOP
by sunshine_august (Scribe) on Sep 13, 2008 at 02:55 UTC
    Patience is as important as these suggestions, don't expect to learn OOP in 24 hours.
Re: looking towards learning OOP
by John M. Dlugosz (Monsignor) on Sep 13, 2008 at 01:44 UTC
    Moose will help you move forward to Perl 6 some day.
Re: looking towards learning OOP
by Anonymous Monk on Sep 12, 2008 at 18:49 UTC
    I'll probably be pummeled for even suggesting this, but I learned OOP in perl by reading Head First Java (which is a very easy read and a GREAT intro to OOP), then used perlboot and perltoot to learn how to apply Java's OO practices to perl. The nice thing about learning Java's way first is Java is pretty strict about what it allows you to do, and perl gives you enough latitude to shoot yourself in the foot if you're not careful (which is the perl way). :)
Re: looking towards learning OOP
by DrHyde (Prior) on Sep 15, 2008 at 10:23 UTC

    The Damian's OO book is very good, and still relevant today. Don't bother with Moose or Spiffy or anything else with a silly name until you understand the basics cos that's what 90% of the code you'll need to maintain will use. Even then, only use SillyNameModule when doing things the normal way is insufficient. And I have yet to find a single case when the normal way is insufficient.

    However, I say all that with one caveat - when I read Damian's book, I already knew how to do OO. Whether it works well as an introduction to OO for a complete beginner I couldn't say. For that, I can recommend the first edition of Java In A Nutshell which is what I learned OO from, but that's been out of print for a long time, and that useful bit was removed from later editions. ISBN 1565921836.

      In my opinion, the "normal way" is always insufficient for anything of greater complexity than "hello, world".

      Myth: Moose is an unnecessary dependency

      Basically, you can not use Moose... but why? Why pass up on something that makes your application go together more quickly and probably results in more correct code?

        They would prefer to learn the fundamentals before using something that does it for them. The same reason why some would like to learn HTML before using Dreamweaver.

        However, there is a line; 'learn how to build a computer from scratch before using it' and so on.

        I'm so adjective, I verb nouns!

        chomp; # nom nom nom

        If you think the normal way is always insufficient, I have to wonder what you're doing wrong. It certainly works well enough for me. And my colleagues. And the authors of most of the objectish modules I ever use.
        because it's documentation is almost ... a joke ?
Re: looking towards learning OOP
by JavaFan (Canon) on Sep 30, 2008 at 12:25 UTC
    I have thought of seriously taking on learning OOP in perl
    I would like to adopt a framework.

    That are two things, which differ more than they overlap. If you want to do the latter, than your suggestions 2) and 3) may be applicable. With moose currently having much more proponents than 3). But in a year or what, moose may be seen as "old" and something more recent will get all the attention.

    But if you want to do the former, forget about focussing on a single implementation. 1) is a good choice, with two caveats. First, it's a few years old and people have come up with several interesting ideas (moose, inside out objects) which aren't covered in Damians book. Second, if you are unfamiliar with OO at all, I recommend you make yourself first familiar with what OO is about, preferably using a book or other literature that doesn't focus on a specific language. OOP focusses a lot on the P aspect (nothing wrong with that by itself), so it may be better to start of with OO in general. After all, there isn't much native OO support in Perl - the programmer has to do a lot.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://710860]
Approved by moritz
Front-paged by pjf
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2018-04-27 05:05 GMT
Find Nodes?
    Voting Booth?