FreeLists / openbeosstorage / [openbeosstorage] Re: Kernel Interface Typedefs

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On Sat, 13 Apr 2002, Tyler Dauwalder wrote:

> Okay, I understand your point now. We shouldn't be including the entire
> interface, just the types we're using for declarations. Good
> observation. If we keep the typedef aliases, we can put the ones that
> need to be public in StorageDefs.Private.h, or something similar.

Or rather move the public typedefs to SupportDefs.h.

> > However, I think, the usage of some of these types is counterproductive
> > anyway. E.g. such as Stat, StatMember and perhaps OpenFlags.
> > The reason for that is, that these aren't opaque in the BeOS API. If you
> > e.g. have a look at the usages of StorageKit::get/set_stat() you will see
> > that in each case a `struct stat*' is passed, although the formal 
> > parameter is StorageKit::Stat.
> 
> Well, the way I see it, they serve two purposes:
> 
> 1. They abstract away the underlying implementation so we can change it
> around as needed. As you pointed out, this is really only true for the
> opaque types like FileDescriptor and Dir, and maybe a couple others; the
> rest of the time, they're simply aliases. 
> 
> 2. They give us a uniform and generally more-descriptive set of types to
> work with. True, they're just aliases for a concrete type that in some
> cases we even end up working with directly. 
> 
> Personally, I like having them. On the other hand, there's not as much
> of a need for any of them to serve as abstractions anymore, now that
> we'll be able to use file descriptors uniformly. I'm not sure I see
> what's counterproductive about using them, though. Could you elaborate
> on that?

Well, actually I was under the impression, that the main purpose of those
types should be to serve as abstractions -- so that they can easily
changed according to the needs of the new kernel, without changing the SK
classes -- which some of them fail to be (e.g. StorageKit::Stat).
Using an abstracting type where actually nothing has to be abstracted from
is counterproductive, because you need to add conversion functions.

> > Thus either conversion functions have to be added or the StorageKit:: type
> > should be removed.
> 
> I don't see why that would be necessary. Just like we don't have a
> conversion function from uint32 to unsigned long. 

That's a basic type and nothing would break, even if uint32 was changed to
float. The conversion functions are inserted implicitly by the compiler.
If we would like StorageKit::Stat to be an abstraction, then we
can't just pass a `struct stat' instead of a StorageKit::Stat to a
function, instead conversion functions would be needed.

However, considering those types, that aren't abstractions, aliases is an
alternative. I hadn't got that idea before. ;-)

CU, Ingo