FreeLists / openbeosstorage / [openbeosstorage] Kernel Interface Typedefs

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> > The reason the StorageKit:: namespace exists, though, is to delineate
> > the parts of the kit that are to be considered private (being open
> > source, we can only hide things so much :-). The doxygen description of
> > StorageKit:: says something to that effect, I believe. So the only place
> > any StorageKit:: members should show up in our public headers are in the
> > private sections of our classes.
> Thus as a consequence the StorageKit:: types have to be declared in a
> public header. Understanding kernel_interface.* as an internal layer
> between the storage kit classes and the kernel, this public header should
> not be kernel_interface.h as it contains a bunch of functions that are not
> meant to be used by the application developer. This implies, that the type
> declarations should be moved out of kernel_interface.h.

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.

> 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?

> 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. 

-Tyler