AnyEventX Namespace?

[Marc Lehmann]

I think a key question you have to ask yourself is: is my module useful
without any AnyEvent knowledge (because it uses AnyEvent only internally, or
is some kind of framework on top of it)?

If yes, it probably shouldn't be called AnyEvent::xxx.

If no, then it might really be useful with AnyEvent only, and then putting it
under AnyEvent should be natural.

On Sun, Sep 09, 2012 at 10:48:04AM -0700, Mike Schilli <anyevent at perlmeister.com> wrote:
> Thing is, my module uses AnyEvent with Object::Event and consumes and emits
> events, so the user should be aware that it's coded that way and tipped off by
> its name.

Well, if it implements a certain something ("SNMP", "web server"), which
already exists, but it does so with AnyEvent, then it's totally useful to
call it AnyEvent::Something, as that advertises "I am the Something for
AnyEvent". If somebody else comes with an alternative implementation he needs
to use a different name - same as with Net::XXX really.

> Now of course we all know AnyEvent doesn't prescribe a particular event
> loop and hence there's no need to point out that it's even involved, but
> it's a certain programming style that I want to advertise. "Async::"
> maybe?

The problem with Async:: is that asynchronous is not the same as event-driven.
The problem with Event:: is that it's kind of polluted by both Event and
Event::Lib already.

It's really hard.

Why don't you look at the existing AnyEvent::xxx distributions on CPAN and
see if you fit in. As I see it, there are two broad categories: modules that
implement a certain protocol and modules that implement some helper
functionality for AnyEvent.

If it doesn't fit in, because it only uses AnyEvent internally, then
anything goes - you could even just call it "Something" instead of
"SomeHierarchy::Something", after all, I didn't put AE or AnyEvent into
some hierarchy.

> You might run into a case, though, where you add a core module to
> AnyEvent:: and someone else on CPAN has already taken the name (which
> you might not even be aware of).

Yeah, deep shit. Evil elmex took AnyEvent::HTTPD away. Oh wait, that would
have been in AnyEventX, and still clash...

I think these collisions happen in any subhierarchy, and I don't think
I should be exempted from it. If somebody would have beaten me to
AnyEvent::DNS or AnyEvent::HTTP, then I would have had to look for another
name.

> If there's a distinct, officially encouraged, AnyEventX (or whatever)
> namespace, there's no potential for conflict. Just a thought.

There is no potential for conflict for the AnyEvent distribution itself,
because it would own AnyEvent::*, but there would still be plently of
conflict for everybody else inside AnyEventX::*, so this only removes a
single distribution from the conflict area. Not even I would be safe, as I
have plenty o "3rd-party" AnyEvent::xxx modules myself.

One could argue that AnyEvent itself is important enough for that, or that it
might make sense to visually differentiate between "official" Anyevent
modules and 3rd-party ones. But personally I think the perl package namespace
is a single collision domain, and something like AnyEventX is a rather
ineffective attempt at avoiding collisions.

Practically, if you wanted to start an AnyEventX namespace, you could do so,
and if it became popular, one could even document it in a prominent place.

But we already have a multitude of "3rd-party" AnyEvent::* modules, so
personally I think that does more harm than good. (And I do admit that I
secretly wanted this to be that way, because CPAN is first-come, first-serve,
and I did wonder if I should ask people to go for AnyEventX and consciously
decided against that. Yeah, I guess I hate these X namespaces :)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\