[M3devel] Pathname.T extensions, was: Re: exposing both path name types?

[Olaf Wagner]

Actually I think it's a good idea to provide platform-specific
interfaces for pathnames in libm3. This way programs can use
the common pathname abstraction in general and special features
of target specific pathnames if they need to. Especially when programming
in a mixed Windows/POSIX environment this will help to keep things
simpler. I'd suggest something like this:

               extends
   Pathname.T   <----  PathnamePosix.T
                <----  PathnameWindows/NTFS.T
                <----  PathnameCygwin.T
                <----  [PathnameDos/FAT.T] (probably no need currently)
                <----  [PathnameOS2.T] (probably no need currently)

(An alternative hinted at above would be to name interfaces after
the actual file systems; there could be different implementations for
UFS, ZFS, NTFS, FAT, HFS, SMBFS, etc. then. This may go too far though.)

Pathname.T should keep all the abstractions that are curently there;
nothing must be changed syntactically or semantically. It may be
extended by an equal predicate (and thus abstract from case differences
if needed) and perhaps more useful methods (arcSeparatorChar/Text(),
hasPlatformSpecificRoot(), ...).

PathnameWindows.T could extend the functionality by methods for
handling of drives and UNC syntax; PathnameCygwin.T could contain
support for /cygdrive/... conversion etc.

All Pathname modules should only depend on pure TEXT functions (i.e.
not platform specific library calls etc.).

All derived types should implement initialization methods for
conversions:

   initFromPosix( PathnamePosix.T )
   initFromWindows( PathnameWindows.T )
   initFromCygwin( PathnameCygwin.T )

Specialized applications like the CM3 builder which are platform
specific to a certain extend could then use standard function calls
to convert between different pathname representations as needed.

Again, I think we should first exactly define the interfaces,
and then provide some unit tests. I'll see if I can find some
old tests as a start.

BTW, the quake functions that were part of the original proposal I sent
to the list are not implemented in quake because they were not really
thought over well; if there are implementations of these in M3
(sysutils), these are just historic relicts and probably not
very general and powerful.

What do the others think?

Olaf

Quoting Jay <jayk123 at hotmail.com>:

> What is the idiom for this:
>
> Currently:
> There is Pathname.i3.
> PathnamePosix EXPORTS Pathname
> PathnameWin32 EXPORTS Pathname
> You can only have one in a link.
>
> It would seem possibly useful to have:
> Pathname.i3 unchanged
> PathnamePosix.i3 identical to Pathname.i3 (some what to avoid the   
> duplication?)
> PathnameWin32.i3 identical to Pathname.i3 (ditto)
>
> On Posix targets:
>   PathnameWin32.m3 exports just PathnameWin32
>   PathnamePosix exports both PathnamePosix and Pathname
>
> On Windows targets:
>   PathnamePosix exports just PathnamePosix
>   PathnameWin32 exports both PathnameWin32 and Pathname
>
> That is Pathname.Foo resolves statically at compile time to the   
> target-specific library.
> PathnameWin32.Foo and PathnamePosix.Foo are also both explicitly available.
>
> These modules each import nothing, except Text. They do all their   
> string manipulation themselves.
>
> Olaf's recent Quake extensions document but don't implement
>     pn_native( pn ) --> text    pn_posix( pn ) --> text    pn_win(   
> pn ) --> text
> As long as pn is a fullpath, these are easy, I just wrote up   
> prototypes, haven't compiled them.
>
> I think these functions might suggest doing what I'm asking about as  
>  well, maybe.
> Or maybe you'd just convert and then never pick back apart.
>
> I have sleazed by for now by using subst_text / to \ and setting up   
> NTFS junctions.
> In this way, I can cross build NT386 <=> NT386GNU either host, either target.
> Had I not done anything, the linker interprets   
> /cygdrive/c/foo/bar.lib as a command switch and says it doesn't   
> understand it.
> Not a big deal, but I think there might be some easy progress here.
>
> This is not just about Pathname.
>
> It is also about File.
> Even though NT386GNU File is FilePosix, it would be useful to allow   
> the serial package to use FileWin32 instead.
> But FilePosix and FileWin32 both reveal the same types.
> It'd be nice if they could expose FilePosix.T and FileWin32.T and   
> then only one of them reveal File.T = FilePosix.T or File.T =   
> FileWin32.T, something like that.
>
>
>  - Jay
> _________________________________________________________________
> Climb to the top of the charts! Play the word scramble challenge   
> with star power.
> http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194