Scott Holben <sholben@mindspring.com> writes:
 ...
>For an application that two of us are starting to architect, I am seeing
>a need to define friendship on the fly, after compile time, to allow
>controller objects to efficiently dig into the private parts of
>subordinate objects directly.  This would allow the subordinate class to
 ...
>Of course, there is the overhead of handing off the keys through the
>correct channels.  But this overhead is typically going to be done
>once.  This will allow the subsequent tight loop access of the master
>object into its subordinate  to occur efficiently.  One could take this
>paradigm a step further to allow the formal key ownership duplicating
>and acquisition, divesting.  This is a paradigm shift away from not
>trusting other programmers by using compiler enforcement to allowing
>superior objects to tango with stable subordinate aggregates.

>I am aware of CORBA, but are there any quick and dirty ways to
>accomplish Dynamic Friendship for Objects using C++ ?  Are there any

I wouldn't call it "friendship", myself, but, anyway, an idea
could be:

class subordinate_access;

class subordinate {
private:
    subordinate* operator&(); // stop just-anybody from getting address
    friend class subordinate_access;
public:
    // "formal key ownership for (acquisition and) divesting"
    void giveupAddress(subordinate *);
    // etc etc
    // in particular: public data, "risky" member functions, whatever
};

class subordinate_access {
    subordinate accessed;
public:
    // only "safe" member functions of subordinate are exported
    // (and delegated to accessed), plus:
    subordinate* obtainAddress(validation data);
};

The idea is that everybody normally only uses a subordinate through
the relevant subordinate_access wrapper; once in a while, for the
sort of needs you see in your design, obtainAddress could be called
and return a valid pointer to the subordinate -- which can then be
accessed freely and "unsafely", until giveupAddress is called to
terminate that "privileged access".  This of course would rely on
trusting successful callers of obtainAddress not to cache copies
of the pointer thus obtained, etc etc -- to move a notch further,
you could have obtainAddress return a smart pointer that invalidates
itself at giveupAddress time, etc etc (but still "protects you from
Murphy, not Machiavelli" -- C++ is a language too replete with
rich, powerful low-level functionality to ensure that malicious
users can't get unexpected access to this sort of thing through,
e.g., reintepret_casts and so on!).

I'm pretty sure that, whatever implementation you have in mind
for your concept that could be imbedded in C++ without invalidating
its existing powerful low-level features (else, it would be out of
the question for any future extension to the standard!!!) and which
would allow maximal-speed access during the time of "friendship"
(no access-control allowed within the tight loop), you can also
implement it pretty smoothly within the language as it stands, via
this sort of pretty-well-known idioms.


Alex
--
 ____    Alex Martelli, Bologna, Italia -- email: alex@magenta.com
 \SM/___                                 http://magenta.com/~alex
  \/\bi/     You never know what is enough unless you know what
     \/          is more than enough.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Holben <sholben@mindspring.com> wrote:

>
>For an application that two of us are starting to architect, I am seeing
>a need to define friendship on the fly, after compile time, to allow
>controller objects to efficiently dig into the private parts of
>subordinate objects directly.  This would allow the subordinate class to
>keep its data private from other yet to be designed superior classes and
>most of the world but when new superior classes are designed the
>subordinate class would not have to be recompiled to allow the explicit
>friendship.  It would also have the advantage of selectively segregating
>friendship at the object level so objects of the same type may not
>necessarily have the friendship "access keys" to dig into a given
>subordinate.

Before I give my suggestion, I would like to clarify the terminology. I
would consider the controller object to be "subordinate" in that it is
dependent on the implementation of the other object, which I will call
the "model" object, in keeping with the Model-View-Controller
terminology.

How about something like this:

struct model_imp
{
  int var1, var2;
  // Add constructor and destructor, if necessary
};

class controller
{
  public:
    void accept_friendship(model_imp*);
// ...
};

class model : private model_imp
{
  public:
    void grant_friendship(controller& c) { c.accept_friendship(this); }
// ...
};

The model object grants "friendship" to the controller object by giving
it a pointer to a public version of its member data (the model_imp
struct). The grant_friendship() function can be made more sophisticated
so as to use some kind of criteria to decide whether or not the request
is valid. If not valid, it could return an error (instead of returning
void) or it could throw an exception.  The criteria could be intrinsic
to the controller object or could be passed as a separate validation
object.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

Languages evolve as the semantics of new ideas get integrated into the
syntax of a language.  Such examples are dynamic memory allocation,  and
the concepts of public, protected, private and friend data.

For an application that two of us are starting to architect, I am seeing
a need to define friendship on the fly, after compile time, to allow
controller objects to efficiently dig into the private parts of
subordinate objects directly.  This would allow the subordinate class to
keep its data private from other yet to be designed superior classes and
most of the world but when new superior classes are designed the
subordinate class would not have to be recompiled to allow the explicit
friendship.  It would also have the advantage of selectively segregating
friendship at the object level so objects of the same type may not
necessarily have the friendship "access keys" to dig into a given
subordinate.

This happens all the time in the real world.   For example, I am a
"person". I have a key to get into my house.  My neighbor is a "person"
and he has a key to get into his house.  However, I can't get into his
house and he can't get into my house directly.  We are not friendly
enough to share our house keys.  So, if I want to go inside his house I
must follow the slower protocol of ringing the door bell, calling a
member function, or risk the associated  repercussions of breaking and
entering.

Of course, there is the overhead of handing off the keys through the
correct channels.  But this overhead is typically going to be done
once.  This will allow the subsequent tight loop access of the master
object into its subordinate  to occur efficiently.  One could take this
paradigm a step further to allow the formal key ownership duplicating
and acquisition, divesting.  This is a paradigm shift away from not
trusting other programmers by using compiler enforcement to allowing
superior objects to tango with stable subordinate aggregates.

I am aware of CORBA, but are there any quick and dirty ways to
accomplish Dynamic Friendship for Objects using C++ ?  Are there any
other ideas as to how to view this problem ?  Or, have I struck a chord
and is it time to integrate this kind of concept into a formal
programming language ?

Sincerely

--
Scott Holben  //   mailto://sholben@mindspring.com
              //   See http://www.skaht.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]