Proposition for change in D regarding Inheriting overloaded methods

[Manfred Nowak]

Walter Bright wrote
> closes all the known hijacking issues.

If accessing data declared private in another not imported module can 
be called hijacking there is at least one more issue:


Defining a Base class:

module def;
class Base{int i;}


and defining a Derived class with some operations and some private data 
`hidden':

module def2;
import std.stdio;
import def;
class Derived:Base{
  private:
  int hidden=41;  // foreign access possible
  public:
  void process( inout Base p){
    scope d= new Derived;
    d.hidden= 666;
    d.i+=1;
    p= d; // no upcast needed
  }
  void read( Base p){
    scope d= cast(Derived)p;  //downcast needed
    assert( d !is null);
    writefln( "def2:", d.hidden);
  }
}


and having a module that does some work:

module mod;
private import std.stdio, def, def2;
public:
void process( inout Base p){
  scope d= new Derived;
  d.process= p; // stores Base, drops Derived
  // do something with d?
}
void read( Base p){
  scope d= new Derived;
  d.read= p; // drops Derived
  // do something with d?
}



the following claim is currently (dmd.1.016,win32) true::

! One can access the `private' data `hidden' defined in `module def2'
! by having access only to sources of `module def' and `module mod'.  


This are about 25 LOC and if D is indeed designed to support auditing 
well, it should be easy to spot that leak.

-manfred