www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Hiding types

reply "Philippe Sigaud" <philippe.sigaud gmail.com> writes:
I'm trying to 'hide' a type, so as not to see it outside its 
module. I want to control the way it's created and used.

I know of Voldemort types and ' disable this', but for now I'm 
just trying to use 'private'. Halas, it seems it can be 
circumvented:

*********

module A;

private struct Hidden {}

Hidden foo() { return Hidden();}

*********

module B;

import A;

void main() {
     typeof(foo()) h;
}

*********

Am I misunderstanding something or is that a bug?
May 30 2014
next sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:

 Am I misunderstanding something or is that a bug?


Try: auto foo() { return Hidden();}
May 30 2014
next sibling parent "Philippe Sigaud" <philippe.sigaud gmail.com> writes:
On Friday, 30 May 2014 at 19:54:00 UTC, safety0ff wrote:

 On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:

 Am I misunderstanding something or is that a bug?


 Try: auto foo() { return Hidden();}


I'm not seeing any difference? I'm still able to create a value 
of type Hidden in an external module.
May 30 2014
prev sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Friday, 30 May 2014 at 19:54:00 UTC, safety0ff wrote:

 On Friday, 30 May 2014 at 19:50:43 UTC, Philippe Sigaud wrote:

 Am I misunderstanding something or is that a bug?


 Try: auto foo() { return Hidden();}


This is incorrect, please ignore.
May 30 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 30 May 2014 15:50:41 -0400, Philippe Sigaud  
<philippe.sigaud gmail.com> wrote:


 I'm trying to 'hide' a type, so as not to see it outside its module. I  
 want to control the way it's created and used.

 I know of Voldemort types and ' disable this', but for now I'm just  
 trying to use 'private'. Halas, it seems it can be circumvented:

 *********

 module A;

 private struct Hidden {}

 Hidden foo() { return Hidden();}

 *********

 module B;

 import A;

 void main() {
      typeof(foo()) h;
 }

 *********

 Am I misunderstanding something or is that a bug?


Even voldemort types can be declared that way. If you want an opaque  
struct, you need to return it by pointer. Otherwise, the user must be able  
to know what type it is (otherwise, how would he use it?)

-Steve
May 30 2014
parent reply "Philippe Sigaud" <philippe.sigaud gmail.com> writes:
On Friday, 30 May 2014 at 20:02:40 UTC, Steven Schveighoffer 
wrote:


 If you want an opaque struct, you need to return it by pointer.


What do you mean? Like this?

Hidden* foo() { return new Hidden();}

?


 Otherwise, the user must be able to know what type it is 
 (otherwise, how would he use it?)


I just fear that by using internal, public, functions, the user 
might get access to a private type. I guess the D answer to that 
is to make foo private also. That makes sense.

I now realize that I implicitly considered 'private' to be 
transitive (or viral). That is that:

Hidden foo() { return Hidden();}

as foo is returning a value from a private type, it should be 
considered private also. By the compiler, I mean.
May 30 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Philippe Sigaud:


 as foo is returning a value from a private type, it should be 
 considered private also.


I think this was discussed, but I don't know why Walter didn't 
design like that. Perhaps someone else can give you an answer.

Bye,
bearophile
May 30 2014
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 30 May 2014 16:09:59 -0400, Philippe Sigaud  
<philippe.sigaud gmail.com> wrote:


 On Friday, 30 May 2014 at 20:02:40 UTC, Steven Schveighoffer wrote:


 If you want an opaque struct, you need to return it by pointer.


 What do you mean? Like this?

 Hidden* foo() { return new Hidden();}

 ?


Yes, this way you can control all aspects of the construction and use. You  
wouldn't need to make it private even, just don't lay out the struct in  
the normal import:

struct Hidden;

I think you would need to use a .di file to do this.


 Otherwise, the user must be able to know what type it is (otherwise,  
 how would he use it?)


 I just fear that by using internal, public, functions, the user might  
 get access to a private type. I guess the D answer to that is to make  
 foo private also. That makes sense.


You can make the struct's methods and data all private, which would  
prevent any useful access to it. But I don't know your use case.


 I now realize that I implicitly considered 'private' to be transitive  
 (or viral). That is that:

 Hidden foo() { return Hidden();}

 as foo is returning a value from a private type, it should be considered  
 private also. By the compiler, I mean.


No, private just makes the symbol not directly accessible. Since foo is  
not private, it's accessible.

-Steve
May 30 2014
parent Philippe Sigaud via Digitalmars-d-learn writes:
 What do you mean? Like this?

 Hidden* foo() { return new Hidden();}


 Yes, this way you can control all aspects of the construction and use. You
 wouldn't need to make it private even, just don't lay out the struct in the
 normal import:

 struct Hidden;

 I think you would need to use a .di file to do this.


OK, I'll try that also. Thank you!



 You can make the struct's methods and data all private, which would prevent
 any useful access to it. But I don't know your use case.


I was trying to imitate some Haskell code in D. The idea was to play
with resources: from a File, create an OpenedFile which cannot be
created except by calling File.open(). And only FileOpened has a
.close() method.
Or something like this, anyway.

But I now realize that I was heading in a wrong direction: private is
not the way to do that: I want the user to know OpenedFile exists. I
just forbid him to create such a value except through File.open(). So
I guess :

struct OpenedFile {
     disable this...
}

is the way to go.

Now I just have to find an explanation on how to use this. I never
touched this part of D.
May 31 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
private in D does not provide any strong guarantees, it only 
controls direct access to the symbol. You effectively want some 
sort of strict internal linkage attribute which does not exist in 
D.
May 30 2014
parent Philippe Sigaud via Digitalmars-d-learn writes:
On Sat, May 31, 2014 at 6:39 AM, Dicebot via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:

 private in D does not provide any strong guarantees, it only controls direct
 access to the symbol. You effectively want some sort of strict internal
 linkage attribute which does not exist in D.


Indeed. I will learn to use ' disable this', then.
May 31 2014