Notice of intention to release Perl module specific to Cygwin

["Soren Andersen" <soren_andersen at speedymail dot org>]

[posted today to module-authors@perl.org; posted to cygwin@cygwin.com
(via Gmane) in order to try to get Cygwin's worthies in the loop].


Subject: Where it runs or what it Does?? (RFC)
Date: Mon, 11 Nov 2002 17:56:00 -0500

-------------------------------------------------------------------
[module-authors@perl.org being asked:]
Hi Good Folks,

"namespace" advice requested. I have written an extension module that I
need to name and get uploaded to CPAN. 

My Subject: line means that as I see it there are two common approaches
to naming modules: where it runs ("BSD::Foo"), or what it does
("Filesys::Bar"). My inclination is to try to use 'what it does' FIRST
and only resort to "where it runs" when I need to make it clear that
there's a special purpose for the module; that it is platform-specific
in some sense. I think this is (at least partially) correct Perl 
philosophy.

The oddball module i've written is for doing some path manipulations on
Cygwin. Cygwin is and yet isn't a "platform"; it's a posix overlayer
running above Microsoft Windows. It emulates *nix to such a degree that
normally we don't think about anything Cygwin-specific needing to be
added; Cygwin Perl is just a very basic vanilla *nix perl with no
special functionality added. Contrast with ActivePerl, which is Win32
Perl and that means special namespaces defined and all sorts of extra
stuff (modules) thrown in. 

But there's a little fly (in my ointment). Cygwin Perl can run in all
sorts of different contexts and be used for many uses. Someday somewhere
somebody is going to be using Cygwinperl and want to have it tell
another application FooMe.exe (thru a 'system()' call, for ex.) that it
wants FooMe to do something with the file
"/cygdrive/r/obscure/directory/dirtypictures.jpg" or "~/.initme_rc" or
"/tmp/*.doc". And that app FooMe is a Windows app that knows nothing
about posix-style paths and will upchuck on the argument.

In fact, I think this HAS already happened, amazingly, to somebody,
somewhere ;-) .

So this module will offer the very simple service of some subroutines
that will take a path as an input arg and return a path. There are four
subs right now (the XSUBS are named something longer; these are perl
subs): 

   posixpath
   win32path
   fullposixpath
   fullwin32path

And they do just about what you'd think.

They access the Cygwin C API through XS glue.

One "trouble" is that conceptually the persons involved with perl on
Cygwin don't all want any sort of Cygwin:: namespace and don't really
agree that there's anything unusual about Cygwinperl that differentiates
it from any generic *nix perl. I know better: on Cygwin, there is always
going to be more than one canonical-ly-correct way to refer to a file by
path name (!!): 

   /posixstyle/file.name    --VS--
   R:\something\mounted\to\posixstyle\file.name

   --and--

   R:/something/mounted/to/posixstyle/file.name

Which last, Cygwin is also perfectly happy to accept and is IMHO the
ideal "happy medium" or lingua franca for most "hybrid" situations on
Cygwin. People are calling this a "mixed" path. 

That's a difference. A psuedo-filesystem difference, IMO. But like it or 
not, find it 'easy to categorize' or not, there IS a difference (between 
generic *nix perl and Cygwin perl).

So my present analysis is that my module belongs in a base namespace of 
"Filesys::" and maybe could be named "CygwinPaths"? I think it would keep 
the maintainer of Cygwin Perl happy -- or should -- if named like this.

What do YOU think?

   Best,
    Soren A


-- 
  conway: unit of mind expansion.
One Conway == ~20 lines of Perl code found
in$CPAN/authors/id/D/DC/DCONWAY, 
which gives the sensation of your brain being wrapped around a brick,
with 
kiwi juice squeezed on top.
	-- Ziggy (via Schwern)

--
http://fastmail.fm - Same, same, but different...

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/