<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
another idea:<br><br>merge UpthreadMachine.i3 and UstatMachine.i3 into just Umachine.i3.<br>Seems like it produces fewer medium sized files instead of more tiny ones but I think I see a drawback too, and until I hear back will go with UstatMachine.<br>Eventually more sharing is probably possible, like of all of Ustat across all platforms, except for struct_stat.<br>And all of Upthread except the sizes of the types and possibly the initializers (Cygwin has non-zero initializers, ideally they are all zero though.)<br>And most of Cstd*. It bugs me to have so many so similar files....<br><br> - Jay<br><br>have moved struct<br>> From: jayk123@hotmail.com<br>> To: m3devel@elegosoft.com<br>> Subject: naming conventions for split/composed interfaces?<br>> Date: Wed, 23 Apr 2008 15:20:41 +0000<br>> <br>> <br>> So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc.<br>> <br>> Look at what I did for example with Upthread.i3 vs. UpthreadMachine.i3.<br>> <br>> Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6 (I386_LINUX), AMD64_LINUX, etc.<br>> <br>> 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.<br>> <br>> So I want to say:<br>> <br>> linux-i386/UstatPlatformSpecific.i3<br>> TYPE struct_stat = ...<br>> <br>> linux-amd64/UstatPlatformSpecific.i3<br>> TYPE struct_stat = ...<br>> <br>> linux-ppc/UstatPlatformSpecific.i3<br>> TYPE struct_stat = ...<br>> <br>> linuxlibc/Ustat.i3<br>> TYPE struct_stat = UstatsPlatformSpecific.struct_stat;<br>> <br>> My question is simply:<br>> <br>> What is the, or a good, naming convention for UstatPlatformSpecific?<br>> <br>> Note that it /could/ be that all but x86 have the same definition, so "PlatformSpecific", might be too, um, specific.<br>> UstatMachine? (Similarly wrong, but maybe no matter, and shorter.)<br>> UstatNotCommon? Sounds dumb.<br>> UstatX? Not as bad as it sounds. There is a precedent. It self-documents the idea that there isn't an obvious good name.<br>> UstatInternal? UstatPrivate?<br>> It's not really about hiding, so much as implementation factoring. But implementation structure is an internal detail.<br>> UstatF? (Friend?)<br>> Ustructstat? no -- ideally, anything in existing Ustat.i3 that varies goess here, not necessarily just this type.<br>> <br>> I do not want fork entire files.<br>> The system is composed of common and uncommon pieces.<br>> I believe the decision where to split should be in general pushed down.<br>> However not without judgement calls.<br>> 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.<br>> Type declarations are usually "must" but in this case largely "nice" (not Ustat, but e.g. Upthreads), and some parts of them "cannot".<br>> <br>> This split/compose pattern, you know, is a way to get something like #ifdef, without any language change or such.<br>> 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.)<br>> <br>> - Jay<br></body>
</html>