[M3devel] naming conventions for split/composed interfaces?

[Jay]

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.
> >
> > I actually think your suggestion is much messier than the current  situation!
> 
> I agree with Tony here: we should keep the structure as simple and
> easily manageable as possible.
> 
> While I understand your idea to join together files based on content
> (or, ultimately, on Unix history) we should keep in mind that a
> minimal amount of code does not always mean the minimal amount
> of maintenance costs, as the underlying systems evolve, too, and may
> (and will) do so in different directions. This may then require a
> different internal structure.
> 
> So I like the idea of keeping different directories for different
> systems, even if there is some redundancy.
> 
> Another argument to keep the structure is that is has proven to be
> easily portable; and we should be very careful to change it.
> 
> Olaf
> -- 
> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080424/eb2d2381/attachment-0002.html>