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

  

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. ;)

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".

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