[M3devel] naming conventions for split/composed interfaces?

[Tony Hosking]

Please, avoid C wrappers wherever possible.

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On Apr 24, 2008, at 6:58 AM, Jay wrote:

>
> Um..I have spent quite some time reading stat.h. At least 5  
> minutes. :)
>
> I must say, I really really really like the copyout method.
>
> Obviously, it goes something like this:
>
>  struct_stat = RECORD
>    st_dev : uint64_t;
>    st_ino : uint64_t;
>    st_mode : uint64_t;
>    st_nlink : uint64_t;
>    st_uid : uint64_t;
>    st_gid : uint64_t;
>    st_rdev : uint64_t;
>    st_size : uint64_t;
>    st_blksize: uint64_t;
>    st_blocks : uint64_t;
>    st_atime : uint64_t;
>    st_mtime : uint64_t;
>    st_ctime : uint64_t;
>  END;
>  struct_stat_star = UNTRACED REF struct_stat;
>
>
> void copyout(const stat_t* s, m3_stat_t* m)
> {
>    m->st_ctime = s.st_stime;
>    ...
> }
> int m3_stat(const char* path, m3_stat_t* m)
> {
>    int result;
>    struct stat s;
>
>    result = m3_stat(path, &s);
>    copyout(&s, m);
>    return result;
> }
>
> and this one type definition and wrapper function is, like,  
> arbitrarily portable to all systems.
> Quite simple. A little inefficient -- but it's not like the stat  
> call itself won't dwarf the copying.
>
> I think I agree merging the files into Umachine.i3.
>
> However consider the part of Ustat.i3 other than the struct.
> The bit masks are probably identical across ALL platforms.
> The function declarations are.
> Actually even the struct can often be factored just by giving types  
> like gid_t, ino_t, but I don't think that's worth it.
> I'd rather uint16_t, uint32_t, uint64_t.
>
> So I think moving just the struct into its own file, or using  
> copyout, not a bad idea.
>
> Ustat.i3 is not quite the best example.
> I think a much better one is Upthread.i3.
> The file is very large and basically I think varies by 3-5 lines per  
> variation.
>
> Lastly, you know, I do work to generate the headers kind of, and/or  
> to derive them somewhat automatically.
> This work should probably be fully automated, at least for test  
> cases, so assert the correctness.
> You know, write Modula-3 and C code to print field offsets and sizes  
> and verify they are identical.
> This should aid maintenability. I assert the current system, no  
> matter how the files are laid out, is overly fragile.
> I assert that transcribing .h files into .i3 files is a very dubious  
> practise.
> It has an upside of easier cross building -- don't need the platform- 
> specific headers.
> And it has the upside of not needing to worry about parsing .h files.
> But it is obviously bad maintainability.
>
> Better would be do wrappers like the above, except where perf is  
> critical.
> Or at least actively (daily) assert the sizes/offsets.
>
>> Another argument to keep the structure is that is has proven to be
>> easily portable; and we should be very careful to change it.
>
> I think the current structure has proven easily copied around and  
> then not fixed and bugs lurking..
> This is not really my original point, but I have to harp a bit, it's  
> been simmering in my brain a long time.
> Any time I see header cloning I cringe significantly. Visual Basic  
> and C# have this same problem.
>
> - Jay
>
>
>
>
>> Date: Wed, 23 Apr 2008 23:32:43 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] naming conventions for split/composed  
>> interfaces?
>>
>> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>>
>>> 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

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