www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implementation hiding

reply so <so so.so> writes:
Hello list,

In one of my never-ending searches to a solution for the infamous  
implementation hiding issue we have with C derived languages, (i don't  
know if other languages have a final solution, anyways irrelevant) today i  
found this article. I have read it before but as it happens i overlooked  
the important part.

The author is someone you might know. (Hint: he also trolls here)

The Counterfeit this:
http://www.artima.com/cppsource/backyard3.html

After i read the related part, the question came up was if it was  
applicable to D.
Patience rewards once again, a few lines later: "These techniques are also  
applicable to the D programming language".

My question is, have any of you tried it or related ideas on this issue?
I didn't try yet but it looks quite promising, i wonder why it is not used  
much as it suggests (and it does) that it solves all the problems with  
Pimpl which is very popular.

Thanks.
Jun 29 2011
next sibling parent reply so <so so.so> writes:
 Caveats:The class Foo cannot have any data members, even hidden ones  
 like a vptr. Therefore, it cannot have any virtual functions.Foo cannot  
 have any constructors, because we aren't constructing a real Foo, only a  
 counterfeit one.


Funny, these two requirements are in fact the starting points for my  
search. I asked many times:

* I don't need any virtual method.
* I don't need a constructor and construction is problematic for this kind  
of work, mass allocation, io and such...

Then why do i have to pay for a vtable or another layer of indirection and  
on top of it an ugly design? There has to be a solution to this! But there  
was none.
Jun 29 2011
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 6/30/11 4:29 AM, so wrote:

 Caveats:The class Foo cannot have any data members, even hidden ones
 like a vptr. Therefore, it cannot have any virtual functions.Foo
 cannot have any constructors, because we aren't constructing a real
 Foo, only a counterfeit one.


 Funny, these two requirements are in fact the starting points for my
 search. I asked many times:

 * I don't need any virtual method.
 * I don't need a constructor and construction is problematic for this
 kind of work, mass allocation, io and such...

 Then why do i have to pay for a vtable or another layer of indirection
 and on top of it an ugly design? There has to be a solution to this! But
 there was none.


The solution is to be able to override new. In Ruby you can do this:

---
class Foo
end

class Bar
   def self.new
     Foo.new
   end
end
---

Now you do:



and as you see, you get a Foo instance.
Jun 29 2011
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 6/30/11 10:30 AM, Ary Manzana wrote:

 On 6/30/11 4:29 AM, so wrote:

 Caveats:The class Foo cannot have any data members, even hidden ones
 like a vptr. Therefore, it cannot have any virtual functions.Foo
 cannot have any constructors, because we aren't constructing a real
 Foo, only a counterfeit one.


 Funny, these two requirements are in fact the starting points for my
 search. I asked many times:

 * I don't need any virtual method.
 * I don't need a constructor and construction is problematic for this
 kind of work, mass allocation, io and such...

 Then why do i have to pay for a vtable or another layer of indirection
 and on top of it an ugly design? There has to be a solution to this! But
 there was none.


 The solution is to be able to override new. In Ruby you can do this:

 ---
 class Foo
 end

 class Bar
 def self.new
 Foo.new
 end
 end
 ---

 Now you do:



 and as you see, you get a Foo instance.


In fact, I don't understand well what's the problem with point 1 in the 
article. If you want to show the users how to use your class, document 
its usage. Don't just throw the code at them...
Jun 29 2011
parent so <so so.so> writes:
On Thu, 30 Jun 2011 06:31:58 +0300, Ary Manzana <ary esperanto.org.ar>  
wrote:


 The solution is to be able to override new. In Ruby you can do this:

 ---
 class Foo
 end

 class Bar
 def self.new
 Foo.new
 end
 end
 ---

 Now you do:



 and as you see, you get a Foo instance.




Ruby is a dynamic language, that is why i said irrelevant :)


 In fact, I don't understand well what's the problem with point 1 in the  
 article. If you want to show the users how to use your class, document  
 its usage. Don't just throw the code at them...


---
Declare the implementation as private:
#include "implementation.h"

class Foo
{
private:
     ... the implementation ...

// the interface
public:
     void bar()
     {
         ... manipulate the implementation ...
     }
};
---

With "point 1" if you mean this one:

For starters it is not an interface but the implementation itself.
Many C users rightly criticize when they see codes like this, most C++  
users won't say anything. It is perfectly fine for your own code, that  
everything is in your hand.

* Nothing is hidden, you can see and change everything.
* Whenever you make a change to the implementation, you also change the  
interface. You have to distribute both.
...

Taft types in C is great. As a result every single C API relies on it.

Well well, i was expecting some discussions.
Looks like my troubles with languages are not among the popular ones!
Jun 29 2011
prev sibling parent so <so so.so> writes:
On Wed, 29 Jun 2011 23:35:30 +0300, so <so so.so> wrote:


 My question is, have any of you tried it or related ideas on this issue?
 I didn't try yet but it looks quite promising, i wonder why it is not  
 used much as it suggests (and it does) that it solves all the problems  
 with Pimpl which is very popular.

 Thanks.


One thing not mentioned in the article, which i think the only problem  
with this technique, destruction.
Walter, would you please point me to the right direction? I can't find  
anything regarding to this.

Thanks!
Jul 02 2011