[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: bobP and simplified ifc
- To: <heh>, <vlad!mark>
- Subject: Re: bobP and simplified ifc
- From: Rick Mascitti <rick>
- Date: Fri, 29 Jun 90 22:45:13 PDT
- Cc: <bobp>, <xtech>
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
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
(Ok, that's a contrived example that can be easily refuted.)
I've had enough "special cases" crop up on me... (how many
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?