Re: bobP and simplified ifc

[Rick Mascitti <rick>]

I *was* suggesting that bobp work on top of all of xpp.  Wanna
have a flame war? :-) 

But serially, folks,

You don't have to have all of the supporting class hierarchy visible
to your clients but, I assert, you *do* need to have that scaffolding
supporting the abstractions you make visible, unless you want to buy
the support burden of changing the interface semantics or the semantic
translation code whenever xpp changes.  You pay for it somewhere.

To be more specific, let's take heh's example.  You make a conscious
decision as to where to "cut" the visibility into the xpp class
hierarchy.  If it's at the "I don't want to have to construct a
f*****g array from its pieces, good (that's the *right* decision).
However, you'd better have your
High_Level_Cplusplus_routine(char *Users_Array)
function mapped into the appropriate
	SPTR(XuArray) foo = ::xuArray(....
shit, automatically, and with well defined expectations as to the
default conditions (i.e., those conditions that *will* occur if you
don't "wallow in the muck" of xpp) unless you want to buy
a lot of grief regarding what
High_Level_Cplusplus_routine(char *&Users_Array[42])
means.
(Ok, that's a contrived example that can be easily refuted.)
I've had enough "special cases" crop up on me... (how many
	SPTR(Foo) foo;`
	Wptr *bar;
	bar = (Wptr *) (Foo *) foo;
examples do you want?)
that the thought of trying to splice XuArrays from an international
class hierarchy frightens me.

maybe this makes sense?
rick