www.digitalmars.com         C & C++   DMDScript  

D - Re-encapsulation

reply J Anderson <REMOVEanderson badmama.com.au> writes:
I would like the concept of re-encapsulation to be available to D 
classes. That is, if it was made public (or protected) in a parent class 
you should be able to make that variable private.  There are many cases, 
where you inherit from a class, and certain methods/variables don't make 
sense at that level.  You could develop an intermediate class, but often 
that can be a lot more work, or you might not be the owner of the parent 
class.

class A
{
public:
    bool Var;

    void T() {  }
private:
    bool X;
}

class B
{
private:
    bool Var; //Same variable as in A
    bool X; //Different variable then in A (ie no change here to current 
rules)
    void T() { }
}

void main()
{
    B b = new B;

    b.T();            //Should cause compilation error as T is not 
visible for B
    b.Var = true; //Should cause compilation error as Var is not visible 
for B

    (cast(A)b).T();   //Should be ok as T is visible for A
    (cast(A)b).Var = true;   //Should be ok as Var is visible for A
}

-Anderson
Dec 15 2003
next sibling parent reply "Charles" <sanders-consulting comcast.net> writes:
Can you give us a real life example where you needed this ?  I like the idea
just to help persuade and all.

C

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:brmca7$2r2h$1 digitaldaemon.com...

 I would like the concept of re-encapsulation to be available to D
 classes. That is, if it was made public (or protected) in a parent class
 you should be able to make that variable private.  There are many cases,
 where you inherit from a class, and certain methods/variables don't make
 sense at that level.  You could develop an intermediate class, but often
 that can be a lot more work, or you might not be the owner of the parent
 class.

 class A
 {
 public:
     bool Var;

     void T() {  }
 private:
     bool X;
 }

 class B
 {
 private:
     bool Var; //Same variable as in A
     bool X; //Different variable then in A (ie no change here to current
 rules)
     void T() { }
 }

 void main()
 {
     B b = new B;

     b.T();            //Should cause compilation error as T is not
 visible for B
     b.Var = true; //Should cause compilation error as Var is not visible
 for B

     (cast(A)b).T();   //Should be ok as T is visible for A
     (cast(A)b).Var = true;   //Should be ok as Var is visible for A
 }

 -Anderson
Dec 16 2003
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Charles wrote:


Can you give us a real life example where you needed this ?  I like the idea
just to help persuade and all.

C

  


I'm not having this problem at the moment, it's an idea that just struck 
me, so I'll have to make it up ;)

* Someones written a frame class, you want most of the abilities except 
the add controls method as your writing an openGL frame. Also you want 
to be able to plug it in to the same polymorphic-interface.
* Someones written a mesh class that uses normals, you want your more 
advanced mesh to compute it's own normals on the fly using smoothing groups.
* Your object accepts mouse input, but you don't want to allow users in 
derived classes to be able to call this event as it's already been 
handled by the event controller.

Another example, could be when a class starts to have more methods then 
nessary and you need to reduce the amount visible to the user, to 
simplify the class.  They can alway access the old methods by casting 
back. Like with programming, you don't want to use the ASM (low-level) 
commands most of the time.

With the methods, I suppose, it would *almost* be the same as 
overloading the particular method with one containing an assert but that 
would be run-time-checking as opposed to compile time.

-Anderson


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:brmca7$2r2h$1 digitaldaemon.com...
  


I would like the concept of re-encapsulation to be available to D
classes. That is, if it was made public (or protected) in a parent class
you should be able to make that variable private.  There are many cases,
where you inherit from a class, and certain methods/variables don't make
sense at that level.  You could develop an intermediate class, but often
that can be a lot more work, or you might not be the owner of the parent
class.

class A
{
public:
    bool Var;

    void T() {  }
private:
    bool X;
}

class B
{
private:
    bool Var; //Same variable as in A
    bool X; //Different variable then in A (ie no change here to current
rules)
    void T() { }
}

void main()
{
    B b = new B;

    b.T();            //Should cause compilation error as T is not
visible for B
    b.Var = true; //Should cause compilation error as Var is not visible
for B

    (cast(A)b).T();   //Should be ok as T is visible for A
    (cast(A)b).Var = true;   //Should be ok as Var is visible for A
}

-Anderson
Dec 16 2003
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
J Anderson wrote:

 I would like the concept of re-encapsulation to be available to D 
 classes. That is, if it was made public (or protected) in a parent class 
 you should be able to make that variable private.  There are many cases, 
 where you inherit from a class, and certain methods/variables don't make 
 sense at that level.  You could develop an intermediate class, but often 
 that can be a lot more work, or you might not be the owner of the parent 
 class.


That sort of butchers the whole idea of what inheritance is.  If part of 
the inherited interface doesn't make any sense, then there is no 'is-a' 
relationship.  Can't derive Apples from Oranges, as they say. ;)

On a more realistic level, doing what you propose would mean that a 
simple downcast would offer access to the method in question. (since 
it's public there)  So now you have to do visibility checking at 
runtime. (ew)

  --andy
Dec 16 2003
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Andy Friesen wrote:


 J Anderson wrote:


 I would like the concept of re-encapsulation to be available to D 
 classes. That is, if it was made public (or protected) in a parent 
 class you should be able to make that variable private.  There are 
 many cases, where you inherit from a class, and certain 
 methods/variables don't make sense at that level.  You could develop 
 an intermediate class, but often that can be a lot more work, or you 
 might not be the owner of the parent class.



 That sort of butchers the whole idea of what inheritance is.  If part 
 of the inherited interface doesn't make any sense, then there is no 
 'is-a' relationship.  Can't derive Apples from Oranges, as they say. ;)


It's meant to be a practical language. I've seen allot of class 
libraries that have been redesigned so many times, because they want to 
add/change something that was not planned for.  Ie you decide to 
computerise a planes interface, so you keep the old version around, but 
you hide it under the dash board.
What about a genetically modified Apple that now resists bugs, now the 
bugspray method doesn't make sense anymore.


 On a more realistic level, doing what you propose would mean that a 
 simple downcast would offer access to the method in question. (since 
 it's public there)  So now you have to do visibility checking at 
 runtime. (ew)

  --andy


I'm only talking about compile time checks, not runtime.  Everything 
would still be available in the VTable, it would just be checked at 
compile time, to see, if the user of that object has access to that 
object.  Since the compiler already knows the type of an object, it just 
needs to say...is this function visible. If it's passed into a function 
and the object type changes, then the visibility changes as well, and 
that's a good thing. I don't see a problem here. You might be able to 
even do something close to this with a static_assert (I hadn't thought 
of that).

-Anderson
Dec 16 2003
parent reply Andy Friesen <andy ikagames.com> writes:
J Anderson wrote:


 I'm only talking about compile time checks, not runtime.  Everything 
 would still be available in the VTable, it would just be checked at 
 compile time, to see, if the user of that object has access to that 
 object.  Since the compiler already knows the type of an object, it just 
 needs to say...is this function visible. If it's passed into a function 
 and the object type changes, then the visibility changes as well, and 
 that's a good thing. I don't see a problem here. You might be able to 
 even do something close to this with a static_assert (I hadn't thought 
 of that).


Sounds like a huge mistake to me.  Now you're implicitly overriding 
methods to throw assertion failures.  These subclasses are now not only 
useless, but dangerous in a polymorphic context, since they now claim to 
implement their superclass's interface, but do not.

  --andy
Dec 16 2003
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Andy Friesen wrote:


 J Anderson wrote:


 I'm only talking about compile time checks, not runtime.  Everything 
 would still be available in the VTable, it would just be checked at 
 compile time, to see, if the user of that object has access to that 
 object.  Since the compiler already knows the type of an object, it 
 just needs to say...is this function visible. If it's passed into a 
 function and the object type changes, then the visibility changes as 
 well, and that's a good thing. I don't see a problem here. You might 
 be able to even do something close to this with a static_assert (I 
 hadn't thought of that).



 Sounds like a huge mistake to me.  Now you're implicitly overriding 
 methods to throw assertion failures.  These subclasses are now not 
 only useless, but dangerous in a polymorphic context, since they now 
 claim to implement their superclass's interface, but do not.

  --andy


I think the compiler should do as I've stated before. The static_assert 
was about trying to do re-encapsulation, with how D is now.  That was 
the same thing with the assert. I think your reading what I've written 
wrong.  The compiler would simply give an error message like "This 
member is private".
Dec 16 2003
parent J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson wrote:


 Andy Friesen wrote:


 J Anderson wrote:


 I'm only talking about compile time checks, not runtime.  Everything 
 would still be available in the VTable, it would just be checked at 
 compile time, to see, if the user of that object has access to that 
 object.  Since the compiler already knows the type of an object, it 
 just needs to say...is this function visible. If it's passed into a 
 function and the object type changes, then the visibility changes as 
 well, and that's a good thing. I don't see a problem here. You might 
 be able to even do something close to this with a static_assert (I 
 hadn't thought of that).




 Sounds like a huge mistake to me.  Now you're implicitly overriding 
 methods to throw assertion failures.  These subclasses are now not 
 only useless, but dangerous in a polymorphic context, since they now 
 claim to implement their superclass's interface, but do not.

  --andy



 I think the compiler should do as I've stated before. The 
 static_assert was about trying to do re-encapsulation, with how D is 
 now.  That was the same thing with the assert. I think your reading 
 what I've written wrong.  The compiler would simply give an error 
 message like "This member is private".


It's something that is supported in C++ but not D.

-- 

-Anderson: http://badmama.com.au/~anderson/
Feb 01 2004