in reply to RFC - Linux::TCPServer (new module)

Since it will run on Linux only, it seems to me that it should be called Linux::Net::TCPServer.

Modules who run on Windows only, have their own Win32::xxx namespace.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Replies are listed 'Best First'.
Re^2: RFC - Linux::TCPServer (new module)
by jdporter (Paladin) on Oct 31, 2005 at 05:36 UTC

    No; they're named Win32::... because they're for interfacing to the Windows system itself, or some subsystem of it.

    We're building the house of the future together.

      I guess that gets at the heart of the matter.

      Just to be clear then, the standard is supposed to be that if the purpose of the module is to expose an OS/platform-specific interface to perl users, then it belongs in the ^Platform:: namespace, whereas if it implements a generic concept with the internals tailored to work on a certain OS/platform, then it belongs in the generic namespaces with the platform tacked on the end?

        if the purpose of the module is to expose an OS/platform-specific interface to perl users, then it belongs in the ^Platform:: namespace,

        whereas if it implements a generic concept with the internals tailored to work on a certain OS/platform, then it belongs in the generic namespaces with the platform tacked on the end?

        I'd say "Yes, generally" to the first part of your question. But I can't think of any precedent for the latter part off the top of my head. A cpan search for "linux" or some such might find some instances of that pattern. Even that wouldn't mean that the convention is blessed by the PAUSE cabal, however.

        We're building the house of the future together.
Re^2: RFC - Linux::TCPServer (new module)
by ph713 (Pilgrim) on Oct 30, 2005 at 17:12 UTC
    I was originally of the Linux:: mind too (obviously), but everyone else so far has gone 3-0 in favor of Net::TCPserver::Linux. I was just about to give in and go start changing the name everywhere this morning when your dissenting opinion arrived, now you've given me an excuse to put it off for at least a few more hours and reconsider it some more :)

      Count one more voice for Net::Server::Linux, that way if someone gets around to adding a Win32 equivalent, it can be Net::Server::Win32, and so on for other platforms. When someone goes looking for a net server, they'll likely find what they are looking for in that namespace regardless of what platform they need it for.

      Win32::* (and by extension Linux::*) are (or should be) reserved for stuff that it simply makes no sense to try and port to other platforms.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Agreed I think. It's just a matter of specifics now. The Net::Server::* namespace currently belongs to a suite of OO modules by one author (Net::Server, Net::Server::PreForkSimple, Net::Server::Proto::TCP, etc), and they all inherit from each other and have a consistent interface.

        I would feel like I was polluting that to stick a module with a different interface into the exact same namespace. Also, Net::Server::* does TCP, UDP, and Unix sockets, whereas my module only covers TCP. And of course, mine's Linux-only, theirs is platform independant pure-perl.

        So brings us back to your first 3-level suggestion, Net::TCPServer::Linux, I guess?

        In the rest of the software world, people give their projects unique names, here in the CPAN world the norm seems to be descriptive names, which seems to make it difficult to have competing implementations in the same namespace. I guess that's the point to some degree, to encourage the idea that everyone contributes to one common best-of-breed implementation of whatever thing it is that category of module can do.