Naming things is hard

So this past week, I finished up the evil arcana known as POEx::Role::SessionInstantiation. Well, at least that is how I ultimately named it. But that decision to name it as such wasn't an easy one to make, largely because I was straddling two separate fiefdoms and neither could seem to agree.

Originally, I had thought of naming the module POE::Session::Moose. At the time, it made sense. It was a Session implemented in Moose, except it was more than that. And it wasn't a subclass of Session per se. So I queried around for possible name ideas with somewhat neutral persons. Fresh on everyone's mind was the idea of using POEx as a root namespace. Matt Cashner actually pushed the idea to the forefront recently with a /topic change in #poe. And since my module was really a Moose::Role, POEx::Role seemed like a great starting point.

Then we kicked around ideas for the last name. Matt Trout suggested readability within the Moose system (ie. ->does(RoleName)) which tickled all the right language processors the right way. Sessionify? Sessionize? Kind of hard to pronounce. SessionInstantiation came up. ->does(SessionInstantiation) reads really well. So it was settled: POEx::Role::SessionInstantiation. Even shortens to something goofy: pxrsi or PEH-ZERCK-SEE. But to make sure I wasn't going to be stepping on anyone's toes by leaping into the POEx namespace first, I broached the topic on #poe.

It was not well received. Many reasons were given, but the biggest reason was control. The POEx namespace from previous conversations on the matter years previous, was supposed to be a reboot and salvation from the POE::Component "swamp." Where the POEx namespace and its descendents essentially define an interlocking, guaranteed behavior. A laudable goal. One that I thought my carefully considered name aligned with. There are many aspects in the POE world that could easily be reimplemented as Roles. As we know from chromatic's evangelizing, Roles == behaviors.

My efforts to get the ball rolling on the conversation, to get a decision made, to get some sort of boundaries drawn around the problem (at least defining the various aspects of the POE world that would be better represented inside a POEx::* namespace) were futile. And finally it was decided that perhaps it would better fit in a Moose namespace (such as MooseX).

Hrm. Not discourage, I started the conversation about naming in #moose. I was met with resistance. "This seems more POE specific than Moose specific." And in the near past, the discussion on having a MooseX::Role namespace was just line noise. So there was no where for me to go. It was offered to perhaps nestle inside MooseX::POE, but that didn't feel right largely because Chris Prather's approach and mine are so completely different.

Eventually, I engage both camps at the same time and let them duke it out. Back and forth on naming happened more or less like a tennis match with each side reasoning against it being in their space. Talk about feeling the love, heh. More suggestions came up to put it in the Class::* namespace, but that doesn't work because it is a Role. Someone thought maybe start a new Top Level Name: Role, but that doesn't suggest Moosiness. But then again, Moose is the only object system that implements Roles in p5. All in all there was a lot of mental masturbation.

And in the end, what was decided? Nothing. Consensus was never reached. So after a few days of that, my new, shiny code was still sitting in a git repo without CPAN distribution. So I was left to decide on my own really. The way that the CPAN indexer works, there are no real constraints on names so long as there isn't a collision. My efforts were mostly to not piss in people's cheerios. And that didn't pan out. Decision by committee simply doesn't occur with any kind of efficiency or expediency. Especially when that committee is made up of two differing groups each with their own ideas and designs on naming things.

POEx::Role::SessionInstantiation stuck. I liked it. It was generated with outside opinions before engaging each camp. It reads nicely in practice. It properly describes the behavior bestowed upon the composed class. And so it was uploaded to the CPAN.

The only good, I feel, that came of this was an absolute refutation of the concept that Perl is a dying language. There are a plethora of cabals out there, each with their own fiefdom in the Perl kindgom. And that is healthy. There are so many expansions of technology within the Perl space, that while we may all not agree on certain things (names for example), we can all agree that our language of choice rocks.