View mode: basic / threaded / horizontal-split · Log in · Help
December 23, 2012
Re: About Go, D module naming
On 12/22/2012 1:04 AM, Jonathan M Davis wrote:
> Walter has completely convinced me with regards to how bad an idea
> compiler warnings are.

Wow!
December 23, 2012
Re: About Go, D module naming
On 12/22/12 9:29 PM, Walter Bright wrote:
> On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
>> Pretty much every time that this issue comes up, people are surprised
>> by the
>> fact that private symbols aren't hidden and pretty much no one wants
>> them to
>> be in overload sets.
>
> This has been discussed before, and the same people wanted private
> functions removed from overload sets in classes.
>
> So why does this never come up in C++ if it's such a problem? Like I
> said, I've never seen this come up on peoples' lists of what they don't
> like about C++, and it isn't because they're shy about complaining about
> C++ :-)

The scope is very different. We're talking classes vs. entire modules 
and, by percolation of symbols, entire applications.

The comparison would be inappropriate, as would be deriving conclusions 
applicable to D from it.

Private inside a module must mean what the person on the street thinks. 
No visibility outside the module at all. There are no two ways about it.


Andrei
December 23, 2012
Re: About Go, D module naming
On Sunday, 23 December 2012 at 02:35:46 UTC, Walter Bright wrote:
> On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
>> I think this is a fallacious argument because it concludes 
>> that apples should be
>> peeled because oranges should.
>
> Given, in C++:
>
> struct S
> {
>   public:
>      void foo(int);
>   private:
>      void foo(float);
> }
>
> void bar()
> {
>     S s;
>     s.foo(1.0f);
> }
>
> This is an error in C++:
>
> foo.cpp:6: error: âvoid S::foo(float)â is private
>
> (I used g++ so nobody would complain this is a defect in dmc++.)
>
> Why does this never come up on peoples' complaints about C++? I 
> spent some time googling it, and came up with nothing.
>
> I don't think it can be dismissed as fallacious unless the 
> why's have a rationale.

I don't see how that example can be compared with the issue 
Jonathan is raising.

If I understood the issue correctly, the visibility of all module 
members are global in scope, and that's why two modules may have 
names that clash. What people want are private module members not 
to be visible outside of the module.

We're speaking about D rather than C++, but I can give you an 
example of how a somewhat analogous situation can cause serious 
problems in C++.

When using dlopen() with the RTLD_GLOBAL flag, it causes all 
symbols from the loaded library to become visible to subsequently 
loaded libraries. When there are symbol clashes, instead of an 
error, one of the symbols is used rather than the other, causing 
the application to behave in unexpected ways.

For dlopen() the default behavior is RTLD_LOCAL, which makes all 
symbols from loaded libs private to their respective libs. This 
is the default behavior to ensure predictable execution 
behaviors, and it's the same default behavior that modules should 
have.

--rt
December 23, 2012
Re: About Go, D module naming
On Sunday, 23 December 2012 at 04:43:27 UTC, Rob T wrote:
> For dlopen() the default behavior is RTLD_LOCAL, which makes 
> all symbols from loaded libs private to their respective libs. 
> This is the default behavior to ensure predictable execution 
> behaviors, and it's the same default behavior that modules 
> should have.
>
> --rt

I meant:

"it's the same default behavior that private module members 
should have.", ie, they should not be visible outside of the 
module.
December 23, 2012
Re: About Go, D module naming
On 12/23/2012 03:35 AM, Walter Bright wrote:
> On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
>> I think this is a fallacious argument because it concludes that apples
>> should be
>> peeled because oranges should.
>
> Given, in C++:
>
> struct S
> {
>    public:
>       void foo(int);
>    private:
>       void foo(float);
> }
>
> void bar()
> {
>      S s;
>      s.foo(1.0f);
> }
>
> This is an error in C++:
>
> foo.cpp:6: error: âvoid S::foo(float)â is private
>
> (I used g++ so nobody would complain this is a defect in dmc++.)
>

structs and classes are utterly irrelevant at this point of the discussion.

Are you aware what the problem Andrei was referring to is?

> Why does this never come up on peoples' complaints about C++? I spent
> some time googling it, and came up with nothing.
>

This is not the primary problem, because it can be avoided by not 
overloading public vs. private against each other.

This is the problem:

module a;
private void foo(){}

module b;
public void foo(){}

module c;
import a,b;
void main() {
    foo(); // error: conflict
}

The error message is misleading. There is no conflict. Nor is there a 
problem. The error is completely spurious.

> I don't think it can be dismissed as fallacious unless the why's have a
> rationale.
>

Modularity is achieved in rather ad-hoc ways in C++. Why do you think 
C++ is relevant?
December 23, 2012
Re: About Go, D module naming
On Sunday, December 23, 2012 05:56:07 Timon Gehr wrote:
> structs and classes are utterly irrelevant at this point of the discussion.

That's mostly true, but UFCS probably makes it so that structs and classes are 
in the same boat as free functions in modules are. Without UFCS, it's a 
relatively minor issue. But since C++ doesn't have UFCS, once again, this is 
an issue that D has that C++ doesn't, making the fact that people don't 
complain about this much in C++ pretty much irrelevant.

- Jonathan M Davis
December 23, 2012
Re: About Go, D module naming
Walter Bright wrote:
> On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
>> Pretty much every time that this issue comes up, people are surprised
>> by the
>> fact that private symbols aren't hidden and pretty much no one wants
>> them to
>> be in overload sets.
> 
> This has been discussed before, and the same people wanted private
> functions removed from overload sets in classes.
> 
> So why does this never come up in C++ if it's such a problem? Like I
> said, I've never seen this come up on peoples' lists of what they don't
> like about C++, and it isn't because they're shy about complaining about
> C++ :-)

	Because C++ *can* hide symbols from other modules with the
anonymous namespace. D has no equivalent.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr
December 23, 2012
Re: About Go, D module naming
Jonathan M. Davis wrote:
> A lint-like tool is free to point them out for you, and maybe an IDE could 
> highlight them, but actually making the compiler consider unused variables to 
> be either a warning or an error would be an incredibly bad idea for D - on top 
> of the fact that it would be really annoying.

I find the notion of warnings with brazillions of compiler flags to be
outdated, anyways. I do want the possibility to obtain more information
from the compiler (in the lint-like fashion), but not in a way that spams
the console and I miss serious information.
So the nice thing to have here would be a standardized interface to the
compiler, or even compiler as a library, with direct data access to this
kind of information. An IDE could then process that, mark unused variables
and other possible errors in funky colors if desired, list them somewhere,
or even show it as an error info in the IDE if the user really wants that.
The user can then directly fade out warnings for code parts known to be
correct on IDE level.
Same thing could be done with custom scripts for the command line folks.
December 23, 2012
Re: About Go, D module naming
On Sunday, 23 December 2012 at 12:20:01 UTC, Tobias Pfaff wrote:
> So the nice thing to have here would be a standardized 
> interface to the
> compiler, or even compiler as a library, with direct data 
> access to this
> kind of information.

Yes the concept of what a complier is, how how it is implemented 
should be redefined. The current concept is monolithic, you 
cannot easily extend it (no one can, not even the compiler devs), 
or make use of it outside of an extremely narrow usage range. 
Restructuring the compiler into a much more flexible and 
extensible tool is something that should be dealt at a later 
point, but there is a much bigger problem that needs to be taken 
on concerning how the language specification is being managed. 
Without a clear language specification that is accessible to 
everyone (try downloading it), and without a defined process to 
manage it, no one really knows fully what the language is 
supposed to be doing, and that limits severely what people are 
able to do in many areas. There's also a huge amount of endless 
discussions that never seem to conclude, and when there is a 
conclusion often the conclusion is not implemented or even 
retained for future reference.

--rt
December 23, 2012
Re: About Go, D module naming
On Sunday, December 23, 2012 12:20:01 Tobias Pfaff wrote:
> So the nice thing to have here would be a standardized interface to the
> compiler, or even compiler as a library, with direct data access to this
> kind of information.

The plan is to have a lexer and parser for D in the standard library, which 
would greatly simplify creating tools that did this sort of thing. We'd 
probably already have the lexer portion (I was working on it earlier this 
year), but I got insanely busy in real life. I'm hoping to get back to it 
fairly soon here though.

- Jonathan M Davis
4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home