On Wednesday, 30 January 2013 at 20:22:11 UTC, Jacob Carlborg wrote:
> On 2013-01-30 17:26, deadalnix wrote:
>
>> The code is in C in the example. But if you replace the C code by
>> another D module, the exact same reasoning holds.
>>
>> What point are you trying to make by raising that ? It seems completely
>> irrelevant to me. Or I didn't inferred the part of the reasoning that
>> was implied in your post. Please make it explicit.
>
> If you have a public and a private function in the same module, it's possible to implement the two functions in two separate object files. The private function must then be available in the object file to link the program properly.

This is why most languages with modules do have their own linker, instead of relying on the 70's constraints of C linkers.

--
Paulo

On 2013-01-31 11:11, Dicebot wrote:

> Ugh, how can you split module into two source/object files? Naive
> approach will result in linker error due to multiple definition of
> ModuleInfo. I did not know it was possible, would have been really cool
> to have.

I'm not 100% sure if it's possible, but it's theoretically possible.

-- 
/Jacob Carlborg

On Monday, January 28, 2013 18:05:37 Dicebot wrote:
> http://wiki.dlang.org/DIP22
> 
> There are two important issues with current protection attribute design:
> 
> * Senseless name clashes between private and public symbols * No way to specify internal linkage storage class
> 
> This DIP addresses both of them with two decoupled proposals:
> 
> * Change of private related name resolution rules
> * Definition of static storage class for module-scope symbols.

I see no point to the internal linkage stuff. What we need is for inaccessible symbols to not be put in overload sets. I'm not sure that it really needs to be any more complicated than that.

- Jonathan M Davis

On Wednesday, 30 January 2013 at 09:42:01 UTC, Dicebot wrote:
> On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips wrote:
>> And this results in people writing code that ...? Is there an example where you can break code in another module by changing something marked as private?
>
> Examples separated:
> http://forum.dlang.org/post/irrbdrxordjawkryvrub@forum.dlang.org

I meant more that these questions should be answered the DIP page.

>> "Compiler errors upon access to private symbol are changed from "%s is not accessible" to "undefined identifier %s""
>>
>> That will just be confusing. You put the name of that symbol because you saw it, being told it is undefined is going to make you think the compiler is broken.

> Also in case of denied access most likely you have put that symbol because of typo, not because you know it (why would you intentionally try to use symbol you already know is private?). And it exposes internal module details by an accident.

My assumption is that I don't know why you put that symbol there. Did you know it was private? Did you intent to make it public? Did you forget what you were doing and entered a random word, were told it was undefined, looked up the source and complained that you could see it?

How you found that the symbol is defined isn't a concern to me, it is the fact that you can verify and be confused that the compiler doesn't see it.

On Wednesday, 30 January 2013 at 09:29:17 UTC, Dicebot wrote:
> Case 1 (binary level, C + D):
>
> ----- sample.d -----
> module sample;
> private int func() { return 42; }
> ----------
>
> ----- oops.c -----
> #include <stdio.h>
>
> extern int _D6sample4funcFZi();
>
> void* _Dmodule_ref = 0;
> void* _D15TypeInfo_Struct6__vtblZ = 0;
>
> void _Dmain() { }
>
> int main()
> {
>     long value = _D6sample4funcFZi();
>     printf("%ld\n", value);
>     return 0;
> }
> ----------
>
> ----- shell -----
> $ dmd - c sample.d
> $ gcc -c oops.c
> $ gcc oops.o sample.o
> ./a.out
> 42
> ----------

Are we really supporting C calling D functions? If we change the function to extern(C) the compiler should probably error if it private.


> Case 2 (pure D, language level):
>
> ----- sample.d -----
> module sample;
> private struct Hest
> {
>     int a, b;
> }
> public alias Hidden UseMe;
> ----------
>
> ----- oops.d -----
> import sample;
> import std.stdio;
>
> void main()
> {
>     UseMe tmp;
>     tmp.a = 42;
> }
> ----------

I think there has been complaint that alias makes symbols public. Though it can be nice to make template instances have nicer names.

Also a similar example:

Hest makeMe() { ... }

-------oops.d------
import sample;

void main() {
    Hest tmp = makeMe();
    int mine = tmp.a;
}

So thumbs up here


> Case 3 (consistency):
>
> I do insist on keeping class and module protection attribute consistent. Saying class privates are always accessible from other modules via tupleof & friends and module privates may be not is causing confusion for no real gain. Also it may break code if we have any means to enumerate module symbols via traits (do we? I don't know).

I'm not sure what you said here. I assume you mean this should work:

class Holder {
    private int stuff;
}

------ Other module----

write("file", myHolder.serialize());

On Wednesday, 30 January 2013 at 11:39:26 UTC, Timon Gehr wrote:
> On 01/30/2013 10:42 AM, Dicebot wrote:
>> ...
>> That was the most uneasy part of proposal. I have been thinking for few
>> hours about it, considering different options. In the end, I have
>> decided that it is only confusing to one coming from C++ lax approach
>> and for clean mind it should make perfect sense that private symbol is
>> indistinguishable from non-existing one in regular user code - that is
>> the point of encapsulation how I get it.
>> ...
>
> As long as compile-time reflection cannot get hold of the error message, the more helpful diagnostic does not do any harm. (After all, the programmer might still be aware of the existence of the member, but missing that it is not accessible (yet) from the module he/she is currently working on.)

I am arguing exactly that it is more helpful as it somewhat breaks encapsulation. I really believe it is good to not give out information that was no supposed to be shown. What do you think about changing both undefined and denied access messages to one "symbol is undefined or inaccessible" then?

On Thursday, 31 January 2013 at 20:43:14 UTC, Jesse Phillips wrote:
> I meant more that these questions should be answered the DIP page.

Sure, I just want to gather more opinions before doing version 2 of DIP. Most likely will gather all together this weekend.

> My assumption is that I don't know why you put that symbol there. Did you know it was private? Did you intent to make it public? Did you forget what you were doing and entered a random word, were told it was undefined, looked up the source and complained that you could see it?
>
> How you found that the symbol is defined isn't a concern to me, it is the fact that you can verify and be confused that the compiler doesn't see it.

Sorry, did not understand this part. Can you give a more code-ish example?

On Thursday, 31 January 2013 at 14:50:05 UTC, Jonathan M Davis wrote:
> I see no point to the internal linkage stuff. What we need is for inaccessible
> symbols to not be put in overload sets. I'm not sure that it really needs to
> be any more complicated than that.
>
> - Jonathan M Davis

I predicted there will be some tension about internal linkage stuff and mostly decoupled it from private stuff so that it can be easily separated into another DIP and implemented in case other part is rejected.

Still, no need for internal linkage is felt because D projects are very small nowadays and does not involve complex separate compilation systems and\or large teams of programmers working on a single project. What internal linkage gives you is hard 100% guarantee (verified by the compiler) that this piece of code may be changed as you wish and it won't affect anything but this module. Private can't give such guarantees without code breakage. It is a widely used idiom in C/C++ that D currently has no replacement.

01-Feb-2013 13:34, Dicebot пишет:
> On Wednesday, 30 January 2013 at 11:39:26 UTC, Timon Gehr wrote:
>> On 01/30/2013 10:42 AM, Dicebot wrote:
>>> ...
>>> That was the most uneasy part of proposal. I have been thinking for few
>>> hours about it, considering different options. In the end, I have
>>> decided that it is only confusing to one coming from C++ lax approach
>>> and for clean mind it should make perfect sense that private symbol is
>>> indistinguishable from non-existing one in regular user code - that is
>>> the point of encapsulation how I get it.
>>> ...
>>
>> As long as compile-time reflection cannot get hold of the error
>> message, the more helpful diagnostic does not do any harm. (After all,
>> the programmer might still be aware of the existence of the member,
>> but missing that it is not accessible (yet) from the module he/she is
>> currently working on.)
>
> I am arguing exactly that it is more helpful as it somewhat breaks
> encapsulation. I really believe it is good to not give out information
> that was no supposed to be shown. What do you think about changing both
> undefined and denied access messages to one "symbol is undefined or
> inaccessible" then?

just tell what it is: not visible, period!

And BTW good dip, the first part.

The second about internal (C's static) is up for more work.

-- 
Dmitry Olshansky

Dicebot, el  1 de February a las 10:42 me escribiste:
> Still, no need for internal linkage is felt because D projects are very small nowadays and does not involve complex separate compilation systems and\or large teams of programmers working on a single project. What internal linkage gives you is hard 100% guarantee (verified by the compiler) that this piece of code may be changed as you wish and it won't affect anything but this module. Private can't give such guarantees without code breakage. It is a widely used idiom in C/C++ that D currently has no replacement.

Unfortunately D is different in this regard than C/C++ (yes, I said
unfortunately :P). Separate compilation in D is not that useful, as
interfaces are not clearly defined (at a file level). When you import
something, you are importing the implementation, not only the interface.
Is really hard to decouple both in D. I tried to play around with
separate (and incremental) compilation in D without much luck. And
I wonder if it ever will make any sense to compile separately instead of
all in one go.

Because of this, even when I agree about the goodness of "static linkage" (as in C/C++), I don't see real value in this proposal for D.

PS: Yes, I know there are the .di files, but even trying to use that
    makes thing extremely hard, because you need to parse the whole file
    to generate it and the difference between parsing and compiling is
    not that much. And then, as in C++, you have templates.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
UNA ARTISTA HACE JABONES CON SU PROPIA GRASA LUEGO DE UNA LIPOSUCCION
	-- Crónica TV