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

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
>

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

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

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

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

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

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/