Date: Tue, 12 Feb 2019 20:13:16 +0000
* If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death.
Drama effects aside, remember that I was the one who called for the creation of this SG so that implementers and tools builders can discuss issues like this and come to agreement on common tasks and notations.
* I do not trust vendors to do the right thing and work together outside of the standard.
I suppose that would mean I give implementers more credit than you do. Maybe it is because Iβm close to them and I can be accused of bias, or something. If you donβt trust them to do the right thing, why would you trust them to implement the Standard at all or if they do they implement it in a way that is useful?
* Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace
That has zero relevance as to what the problem is.
From: tooling-bounces_at_[hidden] <tooling-bounces_at_open-std.org> On Behalf Of Isabella Muerte
Sent: Sunday, February 3, 2019 8:01 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death. If we can't have implementations agree on a singular thing to do, that is going to fragment the community further, cause headaches, and waste hundreds of hours of developer time trying to get everything to work the same. I do not trust vendors to do the right thing and work together outside of the standard.
Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace (which is orthogonal to modules in C++), they have partial classes (which we do not), and they don't have separate interface and implementation files. I reckon if C# had to deal with some of the issues we are, it would be less popular. π
βββββββ Original Message βββββββ
On Sunday, February 3, 2019 7:41 PM, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
I keep reading this. The opposite is just true as well. For example, there are lot of experience with C# out there and their productivity hasnβt gotten down because of it.
Lost in all this brouhaha is the fact that the IS does not preclude a trivial mapping: your implementation will document what it wants.
From: tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On Behalf Of Corentin
Sent: Sunday, February 3, 2019 6:00 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
We don't need it and a lot of us believe we need to not have it.
The price for this level of indirection, as you say is quite high on tooling. the benefits un-existant.
The evolution working group and the authors of the module proposal seem afraid to over specify - while SG-15 thinks
leaving things as they are will lead for decades of pain. At least, I certainly think so.
We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
As for name collision... It's not a problem. It would even be a good thing to make sure not to have duplicated file names:
Module identifier needs to be unique in a program, so asking the same of files is reasonable.
On Mon, 4 Feb 2019 at 02:20 Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi all,
I have been looking for some information why do we need a level of indirection from module name to module interface file name. Why are modules names need a different system then header names.
I have hear that Microsoft was having some problems with name collision. Is there more concrete information about the problem that Microsoft or other companies were having?
If you have a name collision today with headers we would just make another library that wraps one of the two colliding headers. I name the public header of this new library something different and problem solved.
So I donβt understand why are we paying for this level of indirection but I probably just donβt understand the problem.
Scott
_______________________________________________
Tooling mailing list
Tooling_at_isocpp.open-std.org<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C8a5c972e74c44a4a171508d68a5570d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636848496911854729&sdata=iD2TNN1VIf%2F8XtVgCcB%2BqTYEitTPB6Y%2BFx%2FSi9eBvOY%3D&reserved=0>
Drama effects aside, remember that I was the one who called for the creation of this SG so that implementers and tools builders can discuss issues like this and come to agreement on common tasks and notations.
* I do not trust vendors to do the right thing and work together outside of the standard.
I suppose that would mean I give implementers more credit than you do. Maybe it is because Iβm close to them and I can be accused of bias, or something. If you donβt trust them to do the right thing, why would you trust them to implement the Standard at all or if they do they implement it in a way that is useful?
* Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace
That has zero relevance as to what the problem is.
From: tooling-bounces_at_[hidden] <tooling-bounces_at_open-std.org> On Behalf Of Isabella Muerte
Sent: Sunday, February 3, 2019 8:01 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death. If we can't have implementations agree on a singular thing to do, that is going to fragment the community further, cause headaches, and waste hundreds of hours of developer time trying to get everything to work the same. I do not trust vendors to do the right thing and work together outside of the standard.
Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace (which is orthogonal to modules in C++), they have partial classes (which we do not), and they don't have separate interface and implementation files. I reckon if C# had to deal with some of the issues we are, it would be less popular. π
βββββββ Original Message βββββββ
On Sunday, February 3, 2019 7:41 PM, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
I keep reading this. The opposite is just true as well. For example, there are lot of experience with C# out there and their productivity hasnβt gotten down because of it.
Lost in all this brouhaha is the fact that the IS does not preclude a trivial mapping: your implementation will document what it wants.
From: tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On Behalf Of Corentin
Sent: Sunday, February 3, 2019 6:00 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
We don't need it and a lot of us believe we need to not have it.
The price for this level of indirection, as you say is quite high on tooling. the benefits un-existant.
The evolution working group and the authors of the module proposal seem afraid to over specify - while SG-15 thinks
leaving things as they are will lead for decades of pain. At least, I certainly think so.
We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
As for name collision... It's not a problem. It would even be a good thing to make sure not to have duplicated file names:
Module identifier needs to be unique in a program, so asking the same of files is reasonable.
On Mon, 4 Feb 2019 at 02:20 Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi all,
I have been looking for some information why do we need a level of indirection from module name to module interface file name. Why are modules names need a different system then header names.
I have hear that Microsoft was having some problems with name collision. Is there more concrete information about the problem that Microsoft or other companies were having?
If you have a name collision today with headers we would just make another library that wraps one of the two colliding headers. I name the public header of this new library something different and problem solved.
So I donβt understand why are we paying for this level of indirection but I probably just donβt understand the problem.
Scott
_______________________________________________
Tooling mailing list
Tooling_at_isocpp.open-std.org<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C8a5c972e74c44a4a171508d68a5570d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636848496911854729&sdata=iD2TNN1VIf%2F8XtVgCcB%2BqTYEitTPB6Y%2BFx%2FSi9eBvOY%3D&reserved=0>
Received on 2019-02-12 21:13:20