🚀 go-pugleaf

In <4c17cf$k52@oznet03.ozemail.com.au>, John Max Skaller <maxtal@suphys.physics
.su.oz.au> writes:
>I guess the thing to do is be a bit suspicious of the design
>technique. For example: why can the user see the node types
>above at all?

In this particular example, these are low level data structures
which are used to implement higher level data structures.  Those
data structures hide everything.  But due to efficiency concerns,
using indirected pointers is not acceptable (actually, the node
classes are not even virtual for space concerns).  The node
structure is intentionally exposed (since this is a low-level
data structure) but only operations which can VIEW the structure
are publically available.  These operations are used by higher
level code to create iterators, more sophisticated data structures,
etc..

But that code has to see a certain level of detail.  These structures
are sufficiently strong that they can also be used directly by the
user.  The tradeoff is that one type of tree can be substituted for
another type of tree, but not for, say, a hash table.  Where using
the high level structures will allow substitution by a hash table,
but at a minor cost of efficiency (such as engendered by use of
indirection for encapsulation).  Most applications can afford such
costs, but some cannot.  So you need both types of data structures.

But, even with the "high" level data structures, this type of
problem repeats itself in the dual Collection/Iterator heirarchy.

>An idea of how to re-engineer:
>
>  ** Separate the interface and implementation **

As mentioned above, unacceptable due to efficiency considerations.

>I have a similar kind of problem: I have several
>kinds of invasive reference counting smart pointers: they
>need access to a refcnt data member of the object
>they manage. I make it public.
>
>Now, this means the user can screw up the automatic
>memory management. Is this bad?

Yes.  If your "smart" pointers are derived from a common
class then you do have the same problem.  You need to
declare it and its subclasses to be friends in a single
declaration point and to make that data element private.
Ideally, you would export JUST that single data element,
but friendship is, unfortunately, not sufficiently fine-grained
for that.

>I think it's the wrong question. The user has _asked_
>a server (the smart pointer) to manage an object 
>_they_ created. Before that, they could already screw
>up the memory management. By handing over to the smart
>pointer, the user is asking for help -- the smart
>pointer promises to help _provided_ the user doesn't
>go and do something stupid (like manually delete the object).

In a small system, perhaps that attitude is o.k. but in a
larger system the need to write code "protectively" will
disallow that approach.

>But the user can still intervene and take control
>back ... and may actually _need_ to fiddle the 
>reference count. For example .. by inventing
>another kind of reference counting smart pointer! 

If that need is actually anticipated, then the data element
should be protected instead of private.  Or you have the
situation where you need another "friend".

The fundamental issue is that while ideally a class design
can be fully decomposed, there are any number of examples
which REQUIRE less than full decomposition.  And the C++ way
of providing for that is "friend".  Some of those examples fall
into the area where just a single unction needs to be a friend.
And, barring mutually dependent definitions, C++ allows for
that.  There are cases where just a single class needs to be 
a friend.  And C++ allows for that.  But there are also cases,
especially when building frameworks, where an entire class
heirarchy needs to be a friend.  And C++ does not allow for
that.

Which is why I suggested that "friends" be introduced to allow
for the lack.  I would ALSO like to see friendship be more fine
grained so that I can export just a particular data element at
the particular privledge level that I desire.  Perhaps I don't
want EVERYTHING to be shared, just a particular component.
Perhaps I don't want the private information to be inherited
if using a "friends" statement.

>In my opinion, encapsulation of objects is not quite right:
>data structures and functions in an implemtation
>module should have free access to other components
>of the module. [Naturally, the user interface provides
>only managed access].

I disagree with this.

>That is, C++ and other "object" oriented systems
>operate by determining that the granularity
>of the module notion is the class -- which is too
>fine. C++ provides friends to escape this design
>compromise (which seems necessary for linear
>polymorphism).

I will admit that a "larger" encapsulation mechanism could be
useful.  But even within such a mechanism I would want to
use friendship to carefully dole out the ability to interact.

>So it may pay to be a bit sloppier about protection
>of data structures .. since they're largely tools
>for creating representations of abstractions,
>and it is _these_ representations that need to be hidden,
>rather than the details of the tools used to create them.

Again, I disagree here.  I want the strongest encapsulation I
can manage to strictly control access to data element and
methods.


Michael Lee Finney
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]