[M3devel] naming conventions for split/composed interfaces?

[Tony Hosking]

Basically, I hate the idea of tangling together multiple machine- 
dependent systems in the same files.  Yes, it is verbose with  
duplicated functionality, but it *is* separable.  I can delete one set  
of files without breaking builds on other targets.  I hate the idea of  
C wrappers even more!

So, my position remains that while it is verbose having separate  
target-specific directories, at least they are independent and isolated.

I actually think your suggestion is much messier than the current  
situation!

On Apr 23, 2008, at 1:12 PM, Jay wrote:

> ok. stat is an evolutionary mess actually.
>
>
> Tony, Are you against having one Modula-3 definition of the type,  
> arbitrarily defined (any order, no padding, omit the nanoseconds  
> probably) and then wrappers in C to copy the data out? That is very  
> simple and obviously correct and just a tad inefficient. I'm very  
> much leaning toward this. Just for all live Linux variants for now,  
> not anything else (until I see if they have messy slightly hard to  
> read headers -- really, I can read them, or preprocess them, but I  
> am a little off put, others would be more off put and checking my  
> work becomes harder). I think there's gains to be in Cygwin too --  
> you can ask it for not all the fields and have it be faster, you  
> know, if you don't need some complicated made up ino.
>
> Either that, or I rather think I should work out the two or three  
> struct declarations precisely and write non-copying wrappers in  
> Modula-3 that call __lxstat64, __fxstat64, etc., copying the inlines  
> out of the header.
>
> I approach from both sides -- read the header, and have C code print  
> sizes and offsets.
>
> It's a little messy. Read the comments.
> There is a version number parameter to an underlying wrapper function.
> The wrapper is either inlined or statically linked.
>
> I have to check if /usr/include represents all architectures, or  
> just x86 and AMD64.
> It could be that the fork is on 32 and 64.
> It could also be that using stat64 makes it all a little simpler,  
> but still a little messy. I have to see when then was introduced, I  
> assume well before LINUXLIBC6 but I have to check. Even stat64 isn't  
> the same between architectures though, it is split 32bit and 64bit..
>
>  - Jay
>
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] naming conventions for split/composed  
> interfaces?
> Date: Wed, 23 Apr 2008 12:40:23 -0400
>
> Yeah, but in this case they really are for the platform -- header  
> files in /usr/include.   I just want to make sure that we don't  
> slice and dice in ways that multiply the confusion.  Right now, if I  
> know what platform I am on I know where to look in cm3/m3-libs/ 
> m3core/src/unix.  I do try to use generic stuff where possible  
> (witness my darwin-generic, darwin-ppc, darwin-i386, darwin-amd64).
>
> On Apr 23, 2008, at 11:39 AM, Jay wrote:
>
> The point is to reduce massive duplication.
>
> Sometimes we split on ostype, sometimes on wordsize, sometimes on  
> the entire platform, sometimes otherwise.
> Imagine if we always split on entire platform, what a mess that  
> would be.
>
> Upthread.i3 should be nearly identical across all platforms.
>   I know some platforms might have more functions, but the next  
> level up is not split and is therefore consistent in what it uses,  
> so no point in splitting the entire interface.
> Let's not multiply everything out just to change a few lines.
>
> There is too much duplication in the system imho and I'd like to see  
> it reduced.
>
>  - Jay
>
>
> > CC: m3devel at elegosoft.com
> > From: hosking at cs.purdue.edu
> > To: jayk123 at hotmail.com
> > Subject: Re: [M3devel] naming conventions for split/composed  
> interfaces?
> > Date: Wed, 23 Apr 2008 11:33:00 -0400
> >
> > Generally, what I try to do is to make Uxxxxx.i3 files for every
> > corresponding C xxxx.h file. This way, as the C headers change it is
> > easy to figure out where things should go. Why do you need a  
> platform-
> > specific name at all? Simply put it into a platform-specific
> > subdirectory which will then be selectively included by the parent
> > m3makefile. That way, we retain a consistent name for the files
> > containing relevant declarations *across* platforms. Remember, only
> > one of these subdirectories gets included in any given build (these
> > are part of the run-time). So, for simplicity's sake I would argue
> > that you are once more making unneeded complexity where simplicity  
> is
> > needed.
> >
> > So, simply having a "linux-generic" directory, and "linux-amd64" +
> > "linux-ppc" + "linux-x86" subdirectories, each with "Upthread",
> > "Ustat", etc. should work just fine. What's the point in making it
> > more complicated?
> >
> > On Apr 23, 2008, at 11:20 AM, Jay wrote:
> >
> > >
> > > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc.
> > >
> > > Look at what I did for example with Upthread.i3 vs.
> > > UpthreadMachine.i3.
> > >
> > > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6
> > > (I386_LINUX), AMD64_LINUX, etc.
> > >
> > > However struct_stat will not likely be. It appears, though I  
> have to
> > > double check, the difference cannot be abstracted out to pointer-
> > > sized integer types, that the fields are of varying orders.
> > >
> > > So I want to say:
> > >
> > > linux-i386/UstatPlatformSpecific.i3
> > > TYPE struct_stat = ...
> > >
> > > linux-amd64/UstatPlatformSpecific.i3
> > > TYPE struct_stat = ...
> > >
> > > linux-ppc/UstatPlatformSpecific.i3
> > > TYPE struct_stat = ...
> > >
> > > linuxlibc/Ustat.i3
> > > TYPE struct_stat = UstatsPlatformSpecific.struct_stat;
> > >
> > > My question is simply:
> > >
> > > What is the, or a good, naming convention for  
> UstatPlatformSpecific?
> > >
> > > Note that it /could/ be that all but x86 have the same definition,
> > > so "PlatformSpecific", might be too, um, specific.
> > > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.)
> > > UstatNotCommon? Sounds dumb.
> > > UstatX? Not as bad as it sounds. There is a precedent. It self-
> > > documents the idea that there isn't an obvious good name.
> > > UstatInternal? UstatPrivate?
> > > It's not really about hiding, so much as implementation factoring.
> > > But implementation structure is an internal detail.
> > > UstatF? (Friend?)
> > > Ustructstat? no -- ideally, anything in existing Ustat.i3 that
> > > varies goess here, not necessarily just this type.
> > >
> > > I do not want fork entire files.
> > > The system is composed of common and uncommon pieces.
> > > I believe the decision where to split should be in general pushed
> > > down.
> > > However not without judgement calls.
> > > You know, there are things that must be shared, things that are  
> nice
> > > to share, things that are more efficient to share, things that
> > > cannot be shared.
> > > Type declarations are usually "must" but in this case largely
> > > "nice" (not Ustat, but e.g. Upthreads), and some parts of them
> > > "cannot".
> > >
> > > This split/compose pattern, you know, is a way to get something  
> like
> > > #ifdef, without any language change or such.
> > > It does make existing code harder to read, because it is broken up
> > > into more pieces, but code will always be broken up into pieces  
> and
> > > never all in one place and always require some assumption or
> > > tracking down of what the next level down does (until you get to
> > > atoms, quantum physics, and all that), the thing is merely to  
> decide
> > > on just what amount is the right amount (says Goldilocks.)
> > >
> > > - Jay
> >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080423/629e466d/attachment-0002.html>