>The only problem with _that_ is many of our types are intended to be
>opaque. That is, you should not know the structure of a WindowType, and we
>can't make the Win... routines take a "WindowType *" paramater without
>exposing WindowType.
perhaps the original intent was for the objects to be opaque.
for that, the struct's should never have been in the publicly released
header files.
instead, the header file should have contained something like:
typedef ListPtr VoidPtr;
this compiles and gives complete opacity.
i hope it's clear that since the objects were not opaque it is a major
problem to make them opaque now. so far, Palm has been very good about
keeping structs binary compatible for backwards compatibility. it would
break tons of apps to change that now. but even worse, there are tons of
things that are not sufficiently exposed via APIs, and it would be crippling
to the functionality of many apps if the structs were not at least replaced
with thin accessor APIs that allowed direct access to some of the members,
and thick access to others. plus, given the lack of said APIs on any
existing OS, it would be a hellish prospect to try to develop apps that were
compatible with OS 1.0 thru 3.x.
in other words, it's a little late to be thinking about making opaque the
objects that have already been exposed. new objects, sure. but if you're
going to make an object opaque, it needs to have a more complete API set
than most of the existing objects have had.
>to do funny casts. ...I suppose we could typedef WindowType to void for
>this...
typedef FooPtr VoidPtr;
the typing works (or at least it works perfectly for the Win32 headers which
do exactly this).
just don't expose the concept of FooType at all.
>But anyway, that puts us back to having a public "WindowPtr" type that's
>passed around as a cookie outside of the OS, and _that_ means we have to
>create a "ConstWindowPtr" type for the cases where it's constant. <sigh>
if it's a cookie with no exposed structure definition, you don't even have
to make it const.
however, by far the worst offender of the const problem is CharPtr. for
anyone who is trying to actually utilize the compiler's const checking, the
only solution is to manually modify every header. which is not much of a
solution.
