Re: The New DIP Process
On Thursday, 29 February 2024 at 05:44:08 UTC, Brad Roberts wrote: I set them up earlier today. It's entirely possible I missed something while configuring them as it's been just over 6 years since the last new group was added, so do shout if anything looks off. I see that the first two messages already posted made it through, so my confidence is reasonably high. Also worth noting, the news group names are NOT dip.idea and dip.development. They're actually digitalmars.dip.ideas (note the plural) and digitalmars.dip.development. I made the list names just dip.ideas@ and dip.development@ for brevity. Later, Brad Much appreciated, Brad!
Re: The New DIP Process
On Wednesday, February 28, 2024 10:44:08 PM MST Brad Roberts via Digitalmars- d-announce wrote: > On 2/28/2024 7:34 PM, Jonathan M Davis via Digitalmars-d-announce wrote: > > On Wednesday, February 28, 2024 7:18:29 PM MST Mike Parker via > > Digitalmars-d-> > > announce wrote: > >> On Wednesday, 28 February 2024 at 19:24:32 UTC, Jonathan M Davis > >> > >> wrote: > >>> I see that they're up on the NNTP server, and the web forum is > >>> hooked up to them, but there is no mailing list. Is that > >>> forthcoming and just isn't up yet since that takes some time, > >>> or are these lists not going to have mailing lists like the > >>> others? > >> > >> They had to be up on NNTP for them to be added to the forums. I > >> just didn't think about the mailing list. I'll contact Brad. > > > > Thanks. > > > > - Jonathan M Davis > > I set them up earlier today. It's entirely possible I missed something > while configuring them as it's been just over 6 years since the last new > group was added, so do shout if anything looks off. I see that the > first two messages already posted made it through, so my confidence is > reasonably high. > > Also worth noting, the news group names are NOT dip.idea and > dip.development. They're actually digitalmars.dip.ideas (note the > plural) and digitalmars.dip.development. > > I made the list names just dip.ideas@ and dip.development@ for brevity. > > Later, > Brad I was able to subscribe. Thanks! - Jonathan M Davis
Re: The New DIP Process
On 2/28/2024 7:34 PM, Jonathan M Davis via Digitalmars-d-announce wrote: On Wednesday, February 28, 2024 7:18:29 PM MST Mike Parker via Digitalmars-d- announce wrote: On Wednesday, 28 February 2024 at 19:24:32 UTC, Jonathan M Davis wrote: I see that they're up on the NNTP server, and the web forum is hooked up to them, but there is no mailing list. Is that forthcoming and just isn't up yet since that takes some time, or are these lists not going to have mailing lists like the others? They had to be up on NNTP for them to be added to the forums. I just didn't think about the mailing list. I'll contact Brad. Thanks. - Jonathan M Davis I set them up earlier today. It's entirely possible I missed something while configuring them as it's been just over 6 years since the last new group was added, so do shout if anything looks off. I see that the first two messages already posted made it through, so my confidence is reasonably high. Also worth noting, the news group names are NOT dip.idea and dip.development. They're actually digitalmars.dip.ideas (note the plural) and digitalmars.dip.development. I made the list names just dip.ideas@ and dip.development@ for brevity. Later, Brad
Re: The New DIP Process
On Wednesday, February 28, 2024 7:18:29 PM MST Mike Parker via Digitalmars-d- announce wrote: > On Wednesday, 28 February 2024 at 19:24:32 UTC, Jonathan M Davis > > wrote: > > I see that they're up on the NNTP server, and the web forum is > > hooked up to them, but there is no mailing list. Is that > > forthcoming and just isn't up yet since that takes some time, > > or are these lists not going to have mailing lists like the > > others? > > They had to be up on NNTP for them to be added to the forums. I > just didn't think about the mailing list. I'll contact Brad. Thanks. - Jonathan M Davis
Re: The New DIP Process
On Wednesday, 28 February 2024 at 19:24:32 UTC, Jonathan M Davis wrote: I see that they're up on the NNTP server, and the web forum is hooked up to them, but there is no mailing list. Is that forthcoming and just isn't up yet since that takes some time, or are these lists not going to have mailing lists like the others? They had to be up on NNTP for them to be added to the forums. I just didn't think about the mailing list. I'll contact Brad.
Re: The New DIP Process
On Wednesday, 28 February 2024 at 08:46:13 UTC, Richard (Rikki) Andrew Cattermole wrote: As it has already had a lot of back and forth from Walter and me with the help of Adam Wilson (very much appreciated!), it's ready for a development forum post. So Mike, once the forum is up, am I in the clear to start at development? https://gist.github.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e Yeah, go for it.
Re: The New DIP Process
On Tuesday, February 27, 2024 8:28:01 PM MST Mike Parker via Digitalmars-d- announce wrote: > Most of the process takes place in two new forums: DIP Ideas and > DIP Development (dip.idea and dip.development on the NNTP > server). The purpose of the Ideas forum is to determine if > developing the DIP is feasible. The purpose of the Development > forum is to strengthen proposals in development. I see that they're up on the NNTP server, and the web forum is hooked up to them, but there is no mailing list. Is that forthcoming and just isn't up yet since that takes some time, or are these lists not going to have mailing lists like the others? - Jonathan M Davis
Re: The New DIP Process
On Wednesday, 28 February 2024 at 03:28:01 UTC, Mike Parker wrote: After discussion in a recent meeting, we're ready now to start accepting DIPs for review. And that means it's time to announce the new process. Very excited to see this. I've already submitted my own DIP idea to get the ball rolling, and am looking forward to seeing what the rest of the community comes up with.
Re: The New DIP Process
Excellent. I haven't heard anything about my export DIP, the last that was said from Mike is that Walter might want to review it external to the DIP process. Unfortunately no feedback beyond that so unless I'm told otherwise, its DIP TIME! As it has already had a lot of back and forth from Walter and me with the help of Adam Wilson (very much appreciated!), it's ready for a development forum post. So Mike, once the forum is up, am I in the clear to start at development? https://gist.github.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e
The New DIP Process
After discussion in a recent meeting, we're ready now to start accepting DIPs for review. And that means it's time to announce the new process. The main goal of the new process is to reduce the amount of "process". The rules of the prior system were intended to create a moderately high barrier of entry in order to discourage frivolous proposals. In practice, they created an extremely high barrier of entry that also discouraged serious proposals, frustrated several DIP authors who went through the process, created too much of a time sink for everyone involved, and did not allow for early indication of the chances that an author's time and effort would result in a favorable outcome. The new system simplifies the process by putting most of the control in the hands of DIP authors. Some key points: * Feedback begins with the initial DIP idea. * The predefined review rounds are gone. * Multiple DIPs can be under review at the same time. * The DIP author decides when a draft is ready to submit for assessment. Most of the process takes place in two new forums: DIP Ideas and DIP Development (dip.idea and dip.development on the NNTP server). The purpose of the Ideas forum is to determine if developing the DIP is feasible. The purpose of the Development forum is to strengthen proposals in development. The process works as follows. * A potential DIP author (or someone looking for an author) posts a description of the idea in the DIP Ideas forum for community discussion and feedback. Periodically, I'll make sure Walter and Atila are aware of the new idea posts so they can provide their initial thoughts. This should give a potential author a good sense of the DIPs chances, e.g., great idea, go for it; maybe, give it a go if you'd like; no way, no how. Based on this feedback, the potential author can decide whether to proceed with development. * When an author does proceed, then once the initial draft is ready, they should make a new post in the DIP Development forum with a link to the draft for community feedback. They should address feedback as necessary by revising the DIP or explaining why they disagree. The author should expect to allow two or three weeks for feedback just to give stakeholders enough time to process it and formulate an opinion, particularly if they want feedback from Walter and Atila at this stage. * After at least two or three weeks of feedback, the author can contact me when the revised draft is ready. If the extent of revision is significant, I'll ask the author to make a new DIP Development thread for feedback on the new draft. Otherwise, I'll ask the author to submit a PR to the DIP repository. * When the PR is submitted, I'll merge it, assign a DIP number, edit as necessary, and email Walter and Atila for assessment. They'll have two weeks to review it (though depending on circumstances, we can extend that as necessary). As before, they'll accept it, reject it, or ask for modifications. I want to emphasize that though any DIP that makes it to assessment in this new process should theoretically have a strong chance of acceptance, there can never be a guarantee. For example, Walter or Atila or someone else may uncover a major overlooked flaw before the decision is made. Or an author may have proceeded with a DIP that Walter and/or Atila expressed skepticism toward at some point in the Ideas or Development forum and the DIP failed to convince. The key point is that we want the author to know before the first draft whether the DIP has a strong, weak, or near-zero chance, and during development whether they're generally going in the right direction, but no one can offer a 100% guarantee. All potential DIP authors should read the DIP Authoring Process doc here: https://github.com/dlang/DIPs/blob/master/docs/process-authoring.md Once the development is underway, the author should also read the Authoring Guidelines: https://github.com/dlang/DIPs/blob/master/docs/guidelines-authors.md I should note that while we still want the language of the final draft to be semi-formal to formal, it's not something the author needs to be overly concerned about during development. Once the PR is submitted, I'll clean up the language as much as necessary and check with the author to ensure I've not changed the meaning of anything. The guidelines describe some simple things the author can keep in mind during development, but getting the details right is the primary concern at that stage. Finally, I want to make it clear that the new forums will be heavily and strictly moderated. We want focused, on-topic discussion there. On the web interface, each forum will have a banner at the top of the page that includes a link to the forum guidelines: https://github.com/dlang/DIPs/blob/master/docs/guidelines-forums.md With the publication of this announcement, Vladimir will deploy the new forums when he's ready to do so. At that point, the
Re: Preparing for the New DIP Process
On Tuesday, 30 January 2024 at 00:06:26 UTC, mate wrote: On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote: I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java. My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large. To get peace from the forum troll, it might be worth it to add a compiler switch `-privateToTheClass` which errors out when it finds more than one class per file. Let's shut this down please. Thanks.
Re: Preparing for the New DIP Process
On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote: I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java. My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large. To get peace from the forum troll, it might be worth it to add a compiler switch `-privateToTheClass` which errors out when it finds more than one class per file.
Re: Preparing for the New DIP Process
On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:
..
My 2 centimes (cos I live in Switzerland) is that if you're
worried about too much code having access to your private
functions, your module is probably too large.
I'd argue:
(1) this module is not too large. (sure its just for demo the
concept though)
(2) private(this) make complete sense here. There is zero need
for the unittest of have access to count. So why not make that
part of the Widget class design. I don't see any downside
whatsoever. Is it absolutely necessary, well, no. But I like the
design clarity it offers.
module test;
class Widget
{
public:
this() { ++count; }
~this() { --count; }
int numWidgets(){ return count; }
private(this):
static int count;
};
unittest
{
Widget w = new Widget, x = new Widget;
assert(w.numWidgets() == 2);
}
Re: Preparing for the New DIP Process
On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote: On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote: On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote: On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote: * establish support for fleshing out ideas before a DIP is even written It's 2024. That should have been the principle a decade ago Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember. The class vs module level of encapsulation was fleshed out a lot in the forums awhile back. I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments. I also suspect those that did prefer class level private (I believe this is what Atila prefers), it's not high on their list of priorities. I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java. My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large. OpenD has already merged this into master anyway. So people can finally decided for themselves, rather than being told they don't need it and here's a workaround in case you do. Btw. no DIP was required. So if anyone wants an 'option' for "class-private", they can now do it in OpenD, and the this topic/debate is should be well and truly over. Just like const, @safe, etc... private(this) is there to use when your usecase requires as such. No effect on existing D code whatsoever.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote: On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote: On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote: * establish support for fleshing out ideas before a DIP is even written It's 2024. That should have been the principle a decade ago Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember. The class vs module level of encapsulation was fleshed out a lot in the forums awhile back. I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments. I also suspect those that did prefer class level private (I believe this is what Atila prefers), it's not high on their list of priorities. I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java. My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large.
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 22:31:59 UTC, FairEnough wrote: No more comments about this in this thread. I promise. Thank you. For those who don't consider it 'a pile of mush', here is where it 'can' be discussed (freely I hope): It can be freely discussed here, too. Just please stop hijacking threads to do it. As for "pile of mush", it's what the dead horse has been beaten into at this point.
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote: On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote: So 60 some odd posts later... If you want to beat this pile of mush further, please do it in a new thread. Going forward, any posts I see about private-to-the-module which are off topic in any given thread will be happily deleted. You've hijacked enough of them. Thanks! No more comments about this in this thread. I promise. For those who don't consider it 'a pile of mush', here is where it 'can' be discussed (freely I hope): https://github.com/orgs/opendlang/discussions/11
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote: On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote: So 60 some odd posts later... If you want to beat this pile of mush further, please do it in a new thread. Going forward, any posts I see about private-to-the-module which are off topic in any given thread will be happily deleted. You've hijacked enough of them. Thanks! Off topic certainly, but a 'pile of mush'?
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 15:31:24 UTC, Mike Parker wrote: On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote: So 60 some odd posts later... If you want to beat this pile of mush further, please do it in a new thread. Going forward, any posts I see about private-to-the-module which are off topic in any given thread will be happily deleted. You've hijacked enough of them. Thanks! Well I did specifcally say 55+ posts ago that this topic really should be discussed elsewhere. But people continued to discuss it anyway - but only my responses raised your annoyance? Do you mean you would actually allow a thread to discuss this topic, if that were the topic of that thread? Such threads always get hijacked by irritant people completely opposed to this idea, and you end up killing those threads too.
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote: So 60 some odd posts later... If you want to beat this pile of mush further, please do it in a new thread. Going forward, any posts I see about private-to-the-module which are off topic in any given thread will be happily deleted. You've hijacked enough of them. Thanks!
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote:
module test;
@safe:
import std;
class C
{
private(this) int x; // intent: other code in this
module cannnot mutate this.
private(this) int y; // intent: other code in this
module cannnot mutate this.
invariant () { assert (x == y); }
void modifyX() {...}
void modifyY() {...}
}
void foo(C c)
{
c.x = 10; // compiler will not compile this code.
c.modifyX();
}
Thank you for posting a very informative example, i think not
just myself but everyone else on this forum had completely forgot
how class private is supposed to work. In spite of the 1000 or so
posts you've made about it.
Keep up the good work!
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 04:23:06 UTC, Steven Schveighoffer
wrote:
..
the unittest case is also similar -- what happens if you put
the unittest next to the function being tested? It's now in the
class, so it can access "true" private data. Same problems,
this even can happen in Java. I don't see what the difference
is. Same code, same file, just in a different spot? Seems more
like you just need to... not do that.
-Steve
There certainly are things you should not do.
There are also things you want the compiler to stop you doing.
And when you use a programming language, where mutable state
automatically, by default, and at all times, leaks out of the
type into the rest of the module, you may really appreciate the
compilers help sometimes.
That's where private(this) comes in handy.
Now this example is pretty small, but imagine debugging this when
foo() is all the way down on line 3546!
The intent should be right there in the design of the type.
Intent should not be subject to analysis of all the code in the
module.
No need to debug this program below, since it will not even
compile.
module test;
@safe:
import std;
class C
{
private(this) int x; // intent: other code in this
module cannnot mutate this.
private(this) int y; // intent: other code in this
module cannnot mutate this.
invariant () { assert (x == y); }
void modifyX() {...}
void modifyY() {...}
}
void foo(C c)
{
c.x = 10; // compiler will not compile this code.
c.modifyX();
}
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent
with how 'invariant' and 'synchronized' are specified. They
imply class-instance-level private, while the language dictates
module-level. Consider:
```d
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
static void foo(C c)
{
// mutate c
}
}
```
Same thing. Yet would still break with some sort of "class-only
private"
the unittest case is also similar -- what happens if you put the
unittest next to the function being tested? It's now in the
class, so it can access "true" private data. Same problems, this
even can happen in Java. I don't see what the difference is. Same
code, same file, just in a different spot? Seems more like you
just need to... not do that.
-Steve
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 19:58:55 UTC, Jordan Wilson wrote:
..
I believe we are now in the "there is nothing more to be said"
territory (just for the record, I think we both agree the
feature is good, I just don't think the feature is necessary at
all...nice-to-have at best. I suspect we'll agree to disagree).
Jordan
It *is* necessary, if you are like me and want to design types
upfront so you don't have to read all the code in the module to
see which parts of that type are touched outside of the type, and
which are not.
class C
{
private int x;
private(this):
int y = 1;
int w, z;
public void test()
{
y = y + 4;
}
public int getY()
{
return y;
}
}
unittest
{
auto c = new C();
import std;
writeln(__traits(getVisibility, C.y));
static assert(__traits(getVisibility, C.y) ==
"private(this)");
c.x++; // allowed
//c.y++; // not allowed
//c.w++; // not allowed
//c.z++; // not allowed
c.test;
writeln(c.getY);
}
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 11:42:59 UTC, Sergey wrote: On Saturday, 27 January 2024 at 11:17:53 UTC, FairEnough wrote: On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote: .. I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same. Jordan Or ...they might just add it to a fork of D. "[PR ready] Class-level private (in addition to the current module-level private)" https://dpldocs.info/opend/roadmap.html I thought you already has fork with this feature enabled. I integrated these changes into my own fork a long time ago: https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242 I've never looked back, and never had any issue with this feature. It's just works. I prefer to design my class upfront so that it doesn't leak private mutable state. Not outside of the module, and not inside of the module. But should I ever need to leak mutable state into the module, I can do that as well. So I have the best of both worlds. Others don't have that, but I do ;-)
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 19:58:55 UTC, Jordan Wilson wrote: On Saturday, 27 January 2024 at 10:42:26 UTC, FairEnough wrote: On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson I believe we are now in the "there is nothing more to be said" territory (just for the record, I think we both agree the feature is good, I just don't think the feature is necessary at all...nice-to-have at best. I suspect we'll agree to disagree). Its probably more useful if you manage a team of barely competent idiot programmers.
Re: Preparing for the New DIP Process
On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote: On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote: ... That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people. Allowing mutable state to escape - the confines of the type in which it has been declared - into the whole of the module, will inevitably lead to a problem. My first use of the D language demonstrated that this statement is factual. The more 'widespread' D is used, will 'likely' also demonstrate the same. What we need to do is find a way to make the computer explode when somebody does that. Weed out the stupid programmers. ;-)
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 10:42:26 UTC, FairEnough wrote: On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote: ... I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same. Jordan Well D already has class privacy. Would be absurd if it didn't. I said "explicit class privacy", I was meaning the concept you are talking about (it probably wasn't the most accurate phrase). But still none of what you said addresses the questions I put forward. Answers to those questions will form the basis for a need (or not), for private(this). By offering counter questions, I was trying to make a point about the line of questioning itself. But I'll answer anyway. (Q1) Are there any circumstances where a class type might need to retain control over its state from other code within the same module (including unittest code)? I have not come across such a circumstance personally, during my time with languages using higher level encapsulation (D module / Go packages). I can certainly imagine that some would have that need for a particular situation, but I can't think of it. I believe we are now in the "there is nothing more to be said" territory (just for the record, I think we both agree the feature is good, I just don't think the feature is necessary at all...nice-to-have at best. I suspect we'll agree to disagree). Jordan
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 11:17:53 UTC, FairEnough wrote: On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote: .. I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same. Jordan Or ...they might just add it to a fork of D. "[PR ready] Class-level private (in addition to the current module-level private)" https://dpldocs.info/opend/roadmap.html I thought you already has fork with this feature enabled.
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote: .. I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same. Jordan Or ...they might just add it to a fork of D. "[PR ready] Class-level private (in addition to the current module-level private)" https://dpldocs.info/opend/roadmap.html
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote: .. When I first used a dynamically typed language, I was inevitably caught out by type errors. I understood this to be part of the many trade offs all languages make. Yes, but a big bank would not write its financial applications in a dynamically typed language, now would it. In any large complex application, type safety is paramount. D came about as a reaction to C/C++ Same for Swift. Same for Go. But since Go doesn't have a class type, its pointless comparing implementation between Go and D. Much better to compare D and Swift in this regards. There will be some who say 'D did it right', and others who say 'but Swift did it better'. It may depend on the priority a programmer gives to type safety, as to which side they are on. Personally, I don't like being 'caught out by type errors' ;-)
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 08:00:32 UTC, Jordan Wilson wrote: ... I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same. Jordan Well D already has class privacy. Would be absurd if it didn't. So this is not about class privacy per se, nor is it about OOP. It's about whether D should provide an *option* for class privacy within a module, so that the programmer can use it when it is appropriate (e.g. there is other code in the module as well, perhaps even just a unittest, and the programmer wants the compiler to enforce type safe use of that type within that unittest). But still none of what you said addresses the questions I put forward. Answers to those questions will form the basis for a need (or not), for private(this). (Q1) Are there any circumstances where a class type might need to retain control over its state from other code within the same module (including unittest code)? (Q2) What problems could potentially occur when a class types state is always leaked into the module. If your answer to Q1 is no, then there is nothing more to say. If your answer to Q1 is yes, but in this case just put the type in its own module, then you've not really answered the question, since there would be no other code in the module. If your answer to Q2 is none, then there is nothing more to say. If your answer to Q2 identifies one or potential problems, you have an immediate type safety concern that needs to be addressed, somehow. There is no language feature to help you deal with that problem (i.e have the compiler enforce your design). You simply have to avoid putting any other code in the same module (this includes your unittest code). So D's approach to answering these two questions, is you should prevent the circumstance from ever arising by constraining your design to one type per module, and the unittest for that type in its own separate module as well. That will be acceptable to some, and not others. It also raises a final question of whether that is all the D programming language should ever provide to the programmer - a way to avoid these situations by constraining your design. If you answer yes, there is obviously nothing more to discuss. If you answer no, then what can be done about it? As I've mentioned, I think Swift got the balance right.
Re: Preparing for the New DIP Process
On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote: On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote: ... That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people. Allowing mutable state to escape - the confines of the type in which it has been declared - into the whole of the module, will inevitably lead to a problem. My first use of the D language demonstrated that this statement is factual. When I first used a dynamically typed language, I was inevitably caught out by type errors. I understood this to be part of the many trade offs all languages make. The more 'widespread' D is used, will 'likely' also demonstrate the same. I suspect the proportion of users that really care about explicit class privacy and find the workaround of putting a class that needs such privacy into a separate file untenable, will remain the same. Jordan
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 05:14:18 UTC, FairEnough wrote: On Saturday, 27 January 2024 at 04:35:11 UTC, Jordan Wilson wrote: On Saturday, 27 January 2024 at 02:18:29 UTC, zjh wrote: On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote: `module private and no class private` goes against the `consistency, integrity, encapsulation, and redundancy` pursued by D, just to maintain the uniqueness between `D and C++`. This is very `funny` and not what `serious language` should have! Does Go and Python qualify as serious languages? Jordan Go does not have a class type so it's of little value to compare Go to D in this respect. I understood zjh's statement to be about `serious languages`, so it's fair to include Go. Python does have a class type, but no explicit means to declare private members, other than the underscore 'convention'. I don't use python so I don't really know whether and to what extent that convention is followed. But that fact that there is this convention would surely demonstrate some need for it?? The fact that python doesn't _enforce_ this demonstrates there are languages which have accepted a weakening of the concept of pure OOP object encapsulation, in return for something else beneficial to the language (I assume). The only questions for you to ponder are: (Q1) Are there any circumstances where a class type might need to retain control over its state from other code within the same module (including unittest code)? (Q2) What problems could potentially occur when a class types state is always leaked into the module. If I posed these 2 questions to you during a job interview, how would you answer them? (Q1) Are there any circumstances where a programmer might need the guarantees of a safe language? (Q2) What problems could potentially occur when an unsafe language is used? (Q3) Are C/C++ serious languages?
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 04:35:11 UTC, Jordan Wilson wrote: Does Go and Python qualify as serious languages? Of course not!
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 04:35:11 UTC, Jordan Wilson wrote: On Saturday, 27 January 2024 at 02:18:29 UTC, zjh wrote: On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote: `module private and no class private` goes against the `consistency, integrity, encapsulation, and redundancy` pursued by D, just to maintain the uniqueness between `D and C++`. This is very `funny` and not what `serious language` should have! Does Go and Python qualify as serious languages? Jordan Go does not have a class type so it's of little value to compare Go to D in this respect. Python does have a class type, but no explicit means to declare private members, other than the underscore 'convention'. I don't use python so I don't really know whether and to what extent that convention is followed. But that fact that there is this convention would surely demonstrate some need for it?? The only questions for you to ponder are: (Q1) Are there any circumstances where a class type might need to retain control over its state from other code within the same module (including unittest code)? (Q2) What problems could potentially occur when a class types state is always leaked into the module. If I posed these 2 questions to you during a job interview, how would you answer them?
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 02:18:29 UTC, zjh wrote: On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote: `module private and no class private` goes against the `consistency, integrity, encapsulation, and redundancy` pursued by D, just to maintain the uniqueness between `D and C++`. This is very `funny` and not what `serious language` should have! Does Go and Python qualify as serious languages? Jordan
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 01:57:01 UTC, Elias (0xEAB) wrote: On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote: That can end up to be a lot of files needing to be managed, simply to control the escape of state into a module. In case you’re worried about the clarity in your editor’s file list (or in similar tools), try packagizing your modules; that should lead to folders that are easily collapsible. In case you’re worried about running out of inodes on ext4 filesystems, maybe give XFS a try. No, not really worried about running out of inodes ;-) My interests are in types that are correct (in both design and use) and enforcable (at least to a reasonable extent). Without private(this) you cannot determine the intent of that types use by other code in the module. And you certainly cannot enforce it. This is true for all other code, including code for unitttests. Without private(this), you *always* leak *all* of the types state into the rest of the module. Hence the workaround of putting every type in its own module, and every unittest making use of that type in a separate module to that type. Otherwise, leaky state will inevitably bite you (unless you're one of those programmers that never make mistakes).
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote:
..
Any answer to this question has to take into account the other
code in the module.
Of course, I can answer this question.
The code below demonstrates how D made it possible for me to make
a mistake when I first used D (i.e. I had the unittest in the
same module as the class).
Of course now I know, silly me, just put the unittest in its own
file god-damitt!
But here is how that mistake could have been avoided without
having to put that unittest in its very own module:
module someClass;
class C
{
void increment() {++x;}
private(this) int x;
}
unittest
{
auto c = new C;
c.x++; // it seems to me, that this is not what that 'type'
expects.
c.increment(); // Thanks private(this) for helping me not
make that mistake.
}
Re: Preparing for the New DIP Process
On Saturday, 27 January 2024 at 02:12:25 UTC, FairEnough wrote: `module private and no class private` goes against the `consistency, integrity, encapsulation, and redundancy` pursued by D, just to maintain the uniqueness between `D and C++`. This is very `funny` and not what `serious language` should have!
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 22:59:17 UTC, Walter Bright wrote: ... C++ private isn't private, const isn't constant, and one can throw from nothrow functions. But that, vI assume you mean that in C++ you can return pointers/references to private mutable class members, and therefore 'private isn't private'. If that is what you're referring to, then that does not negate the value of class private members in C++. Nor is it argument against an option for class private members *within* a module, in D. There is only 1 valid argument against introducing an option for module level class private members in D. And that is, a programmer (as in all programmers who use D) should never need to control the visibility of a class types mutable state to other code in the same module (including unittests). But is that true? I mean either it is, or it isn't. The option presented, i.e. to put the class type in a module by itself, does not answer this question (since there is no other code in the module). Any answer to this question has to take into account the other code in the module.
Re: Preparing for the New DIP Process
On Friday, 26 January 2024 at 23:41:51 UTC, FairEnough wrote: That can end up to be a lot of files needing to be managed, simply to control the escape of state into a module. In case you’re worried about the clarity in your editor’s file list (or in similar tools), try packagizing your modules; that should lead to folders that are easily collapsible. In case you’re worried about running out of inodes on ext4 filesystems, maybe give XFS a try.
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote: ... That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people. Allowing mutable state to escape - the confines of the type in which it has been declared - into the whole of the module, will inevitably lead to a problem. My first use of the D language demonstrated that this statement is factual. The more 'widespread' D is used, will 'likely' also demonstrate the same. Having a means to control what state can or can't escape into the rest of the module seems like a pretty sensible option to have - at least to me. Again, the only argument that has been put forward against this, is that in D you can put your type into its own module. That is, one module for every class, and for every unittest. That can end up to be a lot of files needing to be managed, simply to control the escape of state into a module.
Re: Preparing for the New DIP Process
On Friday, 26 January 2024 at 22:21:22 UTC, Meta wrote: This is the only valid reason for introducing class-private that's ever been put forth in this forum. I saw someone else post a similar argument around class invariants awhile back as well and it completely changed my mind on the issue. This has been argued before, but in a slightly different manner. Objects have type (i.e. the object is of type class). As a type, it must be able to present its interface to other code in a way that maintains its invariants. In this view, a class is no different to other types in the language, which also maintain their invariants. The key here, is to think of a class as a type. If you don't think that way about classes, then class(private) would seem a pretty useless addition to the langauge. But without a class(private) option, there is simply no way for a class 'type' to maintain its invariants in D, when other code is in the same module as the class. This includes code for unittests. The only workaround in D, is to ensure a module (file) contains no other code other than that single class. While module level visibility is very useful, the usefulness of class level visibility is not really something that anyone should have to justify. A class is a type, and therefore should have the ability to maintains its invariants, even from other code in the same module. That, I would argue, is the primary reason for introducing an option in D for class(private). It's not an argument for OOP. It's an arguement to allow a class type in D, to be able to present itself 'as type that can maintain its own invariants' to other code in the same module. The key part there is 'to other code in the same module'. This cannot occur without a class level visibility attribute. The only argument that be put forward against this arguement, is that in D, you shouldn't ever need to present a class as 'a type that can maintain its own invariants' to other in the same module. But when a programmer has that need, D cannot provide a solution. class(private) would immediately solve that problem, for that programmer.
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent
with how 'invariant' and 'synchronized' are specified. They
imply class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public
interface, but it neither locks on c, nor runs the invariant
checks. I personally have no idea how to fix that sensibly
except by ditching class invariant/synchronized entirely.
This is the only valid reason for introducing class-private
that's ever been put forth in this forum. I saw someone else post
a similar argument around class invariants awhile back as well
and it completely changed my mind on the issue.
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 08:58:29 UTC, Danilo wrote:
You can use `q{}`
```D
string wrap(string f) {
return "void wrap_"~f~"() { "~f~"(); }";
}
void fun() {}
mixin(wrap("fun"));
```
Not only `q{}` will make this even less readable—it won’t even
work.
Re: Preparing for the New DIP Process
On Thursday, January 25, 2024 8:03:41 AM MST Max Samukha via Digitalmars-d-
announce wrote:
> On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
>
> wrote:
> > Of course, ultimately, different programmers have different
> > preferences, and none of us are going to be happy about
> > everything in any language.
>
> It's not only about preferences. The feature is inconsistent with
> how 'invariant' and 'synchronized' are specified. They imply
> class-instance-level private, while the language dictates
> module-level. Consider:
>
> ```
> synchronized class C
> {
> private int x;
> private int y;
>
> invariant () { assert (x == y); }
> }
>
> void foo(C c)
> {
> // mutate c
> }
> ```
>
> With module-level private, 'foo' is part of C's public interface,
> but it neither locks on c, nor runs the invariant checks. I
> personally have no idea how to fix that sensibly except by
> ditching class invariant/synchronized entirely.
Well, sychronized is actually a function attribute, not a class attribute
(TDPL talks about synchronized classes, but they've never actually been a
thing; it was just a planned idea that was never implemented). You can stick
synchronized on the class itself, but it still only affects the member
functions. So, mutating the class object via non-member functions in the
module really isn't any different from mutating the object with member
functions which aren't marked with synchronized. So, if anything here, I
would argue that the confusion comes from being allowed to stick attributes
on a class and then have them affect the member functions. It does allow you
to stick the attribute in one place and then affect the entire class, but
I'm inclined to think that it probably shouldn't have been allowed in cases
where the attribute isn't actually for the class itself.
Of course, the change that I'd really like to see here is synchronized
removed from the language, since I think that it was definitely a misfeature
(along with having a monitor inside of every class instance to allow
synchronized to work, whether the type is shared or not or has an
synchronized methods or not).
Regardless, because synchronized is not at all a class attribute, I don't
agree that it implies anything related to class-level private, much as I can
see how being allowed to put it directly on a class could cause confusion.
As for invariants, all that the spec promises is that they're called when
public member functions are called. So, again, having a module-level
function directly mutate the members doesn't really violate anything.
However, the part there that I do agree is questionable is that because the
module-level function could be public, it makes it so that it's pretty easy
to end up in a situation where an invariant is skipped when the object is
mutated by calling public functions from the module. But there are also
likely to be cases where it's useful to be able to bypass the invariant like
that (though obviously, it then requires that the code maintain the
invariant, just like @trusted code needs to maintain the promises of @safe).
So, I don't think that it's necessarily a problem that the language works
this way, but it's certainly true that it's something to be mindful of. And
if you want to explictly run the invariant in such sitations, then you can
just assert the class reference. But as with anything related to private, if
you want to guarantee that something only accesses an object via its public
API, you can always just put it in another module.
- Jonathan M Davis
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent
with how 'invariant' and 'synchronized' are specified. They
imply class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public
interface, but it neither locks on c, nor runs the invariant
checks. I personally have no idea how to fix that sensibly
except by ditching class invariant/synchronized entirely.
Is there issue with module-private, invariant, and synchronized
solely the result of the interaction between all three? Or is
there an issue with module-private and invariant by themselves
(i.e. if C is not synchronized)?
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:14:30 UTC, zjh wrote: `private to module `, goes against `consistency, completeness, and redundancy` pursued by D, just to maintain the `uniqueness` between `D and C++`! It is just very funny!
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public
interface, but it neither locks on c, nor runs the invariant
checks. I personally have no idea how to fix that sensibly
except by ditching class invariant/synchronized entirely.
`private to module `, goes against `consistency, completeness,
and redundancy` pursued by D, just to maintain the `uniqueness`
between `D and C++`!
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent with
how 'invariant' and 'synchronized' are specified. They imply
class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public interface,
but it neither locks on c, nor runs the invariant checks. I
personally have no idea how to fix that sensibly except by
ditching class invariant/synchronized entirely.
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 07:56:50 UTC, Ogi wrote:
String mixins are one the D’s killer features but the lack of
string interpolation make them look like a mess.
You can use `q{}`
```d
mixin(q{
static foreach(p; __traits(parameters))
{{
enum pname = __traits(identifier, p);
static if(__traits(hasMember, this, pname)) {
__traits(getMember, this, pname) = p;
pragma(msg, "found member: " ~ pname);
pragma(msg, __traits(getAttributes, p));
pragma(msg, __traits(getAttributes, typeof(pname)));
//pragma(msg, p);
}
}}
});
```
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 00:19:54 UTC, Jordan Wilson wrote: I can only assume lack of string interpolation was causing pain to more users, than a lack of class private, therefore it got implemented first. String mixins are one the D’s killer features but the lack of string interpolation make them look like a mess.
Re: Preparing for the New DIP Process
On Wednesday, 24 January 2024 at 22:32:12 UTC, FairEnough wrote: On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote: But the argument that it cannot cause a problem, is already shown to be wrong. So it is good, that unit tests helped you to find how language is designed! Good feature
Re: Preparing for the New DIP Process
On Wednesday, 24 January 2024 at 22:32:12 UTC, FairEnough wrote: But the argument that it cannot cause a problem, is already shown to be wrong. D official is unwilling to `solve` the problem, `stubbornness` has been seen!
Re: Preparing for the New DIP Process
On Wednesday, 24 January 2024 at 22:32:12 UTC, FairEnough wrote: On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote: ... but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works. But the argument that it cannot cause a problem, is already shown to be wrong. That wasn't what was said. What was said was "causing US problems". I.e. on the whole, the lack of class-level privacy does not appear to be causing widespread problems, which implies that it's simply lower on the list of feature requests for most people. Let me put it another way. I'm not against class private. I'm not against string interpolation. I don't care about class private. I don't care about string interpolation. One will soon be in the language, and one will not. I can only assume lack of string interpolation was causing pain to more users, than a lack of class private, therefore it got implemented first. Jordan
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote: ... but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works. - Jonathan M Davis I don't agree. The first time I used the D language, I discovered a 'problem'. That is, my unittest inadvertently accessed a private member of a class, instead of using the public interface of the class. Now the problem of course was me, the programmer (at least one could argue that). But to me, the problem was the language, for not having a feature that could have avoided this problem in the first place. Now, if I want to use D to program, I have to ensure I don't make the same mistake again, by putting my unittest into there own source files (since the compiler cannot warn me, since the language has no feature to make my intent explicit to it). That problem has not gone away, and nor can it, without splitting up everything it own source file. Whether it makes sense to change it now, is a separate argument (and not really one I want to get into, since the arguments against it are always just fluff, and not worthy of my attention). But the argument that it cannot cause a problem, is already shown to be wrong.
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 22:59:17 UTC, Walter Bright wrote: C++ private isn't private, const isn't constant, and one can throw from nothrow functions. TIL C++ is worse than anticipated.
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:01:54 UTC, Walter Bright wrote: On 1/21/2024 3:51 AM, zjh wrote: When you need `friend`, You can put them all in one module. Sometimes, when `multiple classes` are closely related and independent, `class level privacy` becomes very important. No one wants , someone from outside may secretly steal money from your home. D does not allow a different module accessing private class members. Private access is limited to the module enclosing that class. This encourages a different use of modules than C++ "toss code randomly into different source files." These are redherring arguments against a robust principle of OOP. A private attribute within a class (visible only to that class) does not mean people can now go and 'toss code randomly into source files. Nor should it be compared to people wanting 'non-constant const, impure pure, and GC allocating @nogc.' Nor would it require D adopting the C++ notion of friends. (all source in a D module is already the D like friend feature anyway, it just implicit). Nor should it be classified as a 'bad' feature because of maintenance costs. Nor is it an argument that D move away from module level privacy. These are all redherring arguments. There doesn't seem to be any real technical reason as to why D should not allow that option. Swift has done this successfully (for example). There are only ever redherring arguments put forward, along with the usual 'we don't do it that way in D' argument. I'm not here to argue for the feature anyway. But given the importance of class-private in OOP, I'd just like to see much better thoughtout arguments against it. (i.e technical/engineering arguments, not the fluff that always accompanies this topic. Putting everything into there own source files, and this includes unittests of course (since they too can end up inadvertingly testing the wrong part of a class), is a solution - but a solution for some, but not others. Anyway, this topic really belongs elsewhere now. But if/when it does popup again, can we please hear better arguments against it, rather than the fluff above, which is not at all convincing.
Re: Preparing for the New DIP Process
On Tuesday, 23 January 2024 at 07:29:33 UTC, Danilo wrote: The people who still put 50,000 LOC into a single file will not be happy with this. ;) Fair enough. I'm also not happy with their code.
Re: Preparing for the New DIP Process
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis wrote: Of course, ultimately, different programmers have different preferences, and none of us are going to be happy about everything in any language. So, of course, there are going to be some folks who are unhappy with how D defines private, but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works. The people who still put 50,000 LOC into a single file will not be happy with this. ;)
Re: Preparing for the New DIP Process
On Monday, January 22, 2024 4:01:54 PM MST Walter Bright via Digitalmars-d- announce wrote: > On 1/21/2024 3:51 AM, zjh wrote: > > When you need `friend`, You can put them all in one module. > > Sometimes, when `multiple classes` are closely related and independent, > > `class level privacy` becomes very important. No one wants , someone from > > outside may secretly steal money from your home. > > D does not allow a different module accessing private class members. Private > access is limited to the module enclosing that class. > > This encourages a different use of modules than C++ "toss code randomly into > different source files." It also greatly simplifies having to deal with visibility attributes. I can understand folks being concerned about it at first, but in practice, it really isn't a problem. If it really is a problem for a piece of code to have access to something private that's in the same module, then you can simply put them in separate modules, and if your module is large enough that you can't keep track of that sort of thing like you need to, then it should probably be split up. And for those cases where you need cross-module access without it being public, there's always the package attribute. The end result is that visibility attributes are very easy to reason about, and you don't have to worry about them much. I really think that the folks who insist on having private be private to the class/struct (or who insist on a new attribute which does that) are just too tied to how other languages work and haven't given D's approach a chance. I don't think that I have _ever_ seen a problem stem from the fact that D's private is private to the module. And in fact, it causes so few issues that way that plenty of folks end up being surprised to find out that it works that way, because they've never run into a situation where it actually mattered that it wasn't private to the class/struct. Of course, ultimately, different programmers have different preferences, and none of us are going to be happy about everything in any language. So, of course, there are going to be some folks who are unhappy with how D defines private, but it's not a feature that has actually been causing us problems, and it really doesn't make sense at this point to change how it works. - Jonathan M Davis
Re: Preparing for the New DIP Process
On 1/21/2024 3:51 AM, zjh wrote: When you need `friend`, You can put them all in one module. Sometimes, when `multiple classes` are closely related and independent, `class level privacy` becomes very important. No one wants , someone from outside may secretly steal money from your home. D does not allow a different module accessing private class members. Private access is limited to the module enclosing that class. This encourages a different use of modules than C++ "toss code randomly into different source files."
Re: Preparing for the New DIP Process
On 1/21/2024 3:46 AM, Dom DiSc wrote: `class-private` is superfluous cruft. You can very easy live without it. And it has only no side effects, if it is implemented without `friend`s. But without this misfeature it is incomplete. Therefor it was decided not to implement it. It would be ok for me to add `class-private` as is, but only with the guarantee that `friend`s will never be added, no matter how much the people using it cry, because it is sometimes unusable without them. The irony is that the presence of class private in C++ wound up motivating the friends feature, which violates private left and right. D did it right with module level privacy, which is enforced. C++ private isn't private, const isn't constant, and one can throw from nothrow functions. D users do ask for non-constant const, impure pure, and GC allocating @nogc. You *can* do these things in D by using forcible casts in @system code. The salient difference between that and C++ is that the D compiler still assumes those invariants are in force, whereas C++ compilers cannot.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 12:53:22 UTC, zjh wrote: This is `harmless`, you only need to add a keyword, but you meet the `user's` needs. Nope, not harmless. It will have maintenance cost.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 12:53:22 UTC, zjh wrote: `Class level private`, increasing one's own selectivity. Adding `redundancy` has always been what Walter hopes for, `hasn't` it? Moreover, `modules, classes, and variables` private are considered complete. I don't understand why just drop out `class level private` ? Just because this is a C++approach, it appears to be the same as C++ `without any style`?
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 12:17:28 UTC, Dom DiSc wrote: All that's possible with class-private is also possible with module-private. But module-private don't has the friends-issue. Everything is good - you only need to realize that. A file, just `one class`, sometimes I hope so, but sometimes I don't want so. I want several `classes` to be closely related but `independent` together! This is `harmless`, you only need to add a keyword, but you meet the `user's` needs. `Class level private`, increasing one's own selectivity. Adding `redundancy` has always been what Walter hopes for, `hasn't` it?
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 11:51:59 UTC, zjh wrote: When you need `friend`, You can put them all in one module. Jup. But putting things in one module won't do anymore if you use class-private. That's why people using it will soon realize they need friends. But friends are a security hole, rendering private completely useless at all. So adding class-private without friends is an incomplete feature, that will make nobody happy. But class-private with friends is a misfeature. Ergo: do not add class-private at all! All that's possible with class-private is also possible with module-private. But module-private don't has the friends-issue. Everything is good - you only need to realize that.
Re: Preparing for the New DIP Process
If you have difficulties to see the logic of module-private, think of a module as a flat: If you don't want someone to mess with your private stuff, don't live with him in the same flat! Be ensured, locks on every cupboard won't do. You cannot prevent someone within the same flat from messing with your private stuff. Most people realize that at some point in their life, so only few live together in the same flat. I hope you will also realize at some point in your life, that two classes should not live in the same module - except they are close friends.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 11:46:42 UTC, Dom DiSc wrote: It would be ok for me to add `class-private` as is, but only with the guarantee that `friend`s will never be added, no matter how much the people using it cry, because it is sometimes unusable without them. When you need `friend`, You can put them all in one module. Sometimes, when `multiple classes` are closely related and independent, `class level privacy` becomes very important. No one wants , someone from outside may secretly steal money from your home.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:52:59 UTC, zjh wrote: On Sunday, 21 January 2024 at 07:51:00 UTC, zjh wrote: You don't know the `pain `of not having a certain feature, And this feature has already been `implemented`, even without `any side effects`! `class-private` is superfluous cruft. You can very easy live without it. And it has only no side effects, if it is implemented without `friend`s. But without this misfeature it is incomplete. Therefor it was decided not to implement it. It would be ok for me to add `class-private` as is, but only with the guarantee that `friend`s will never be added, no matter how much the people using it cry, because it is sometimes unusable without them.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote: On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote: I also suspect those that did prefer class level private (I believe this is what Atila prefers), it's not high on their list of priorities. I wouldn't pay too much attention to him, it's the same guy who bows a gasket every time it comes up. Like he is literally unable to use D without it. I think he's like 12 yo or something.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:51:00 UTC, zjh wrote: You don't know the `pain `of not having a certain feature, And this feature has already been `implemented`, even without `any side effects`! They just ignore you!
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:46:07 UTC, Jordan Wilson wrote: What? I'm sorry, but being happy with module level != not caring about others. Jordan You don't know the `pain `of not having a certain feature,
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:36:31 UTC, zjh wrote: On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote: I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments. So there are very few people in the D community. If you don't care about others, they don't care about you. What? I'm sorry, but being happy with module level != not caring about others. Jordan
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:36:31 UTC, zjh wrote: So there are very few people in the D community. If you don't care about others, they don't care about you. [here](https://github.com/opendlang/opend/pull/30) A small feature that has no side effects at all. They are just not merging it.
Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote: I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments. So there are very few people in the D community. If you don't care about others, they don't care about you.
Re: Preparing for the New DIP Process
On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote: On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote: * establish support for fleshing out ideas before a DIP is even written It's 2024. That should have been the principle a decade ago Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember. The class vs module level of encapsulation was fleshed out a lot in the forums awhile back. I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments. I also suspect those that did prefer class level private (I believe this is what Atila prefers), it's not high on their list of priorities. Jordan
Re: Preparing for the New DIP Process
On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote: .. For those newcomers who don't know what that was all about.. https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242
Re: Preparing for the New DIP Process
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote: * establish support for fleshing out ideas before a DIP is even written It's 2024. That should have been the principle a decade ago Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember. ... Previously, I'd always considered development of the DIP separate from the DIP "process", which I saw as beginning with the submission of a pull request. In reality, the process begins even before an author opens an editor to start typing. I hope that by recognizing that, and by providing support for discussing ideas and writing the DIP, we'll foster an environment that still maintains a relatively high bar for DIPs that get submitted, but also creates a filter such that potential DIP authors can be more confident that they aren't wasting their time once they get to the development stage. By the time they get there, they'll have no doubt if it's an idea worth pursuing. Bring back the privateThis discussion, so we can put your newly discovered revelations to the test. Maybe the folks over at openD can try discussing it too, and see what happens there ;-)
Re: Preparing for the New DIP Process
This is going to be a great initiative. Thanks, Mike!
Re: Preparing for the New DIP Process
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote: And by "quality" I'm not referring to the quality of the DIP's language. In the new process, the focus will be entirely on the details of the proposal and not on the language in which they're presented. I'm happy to clean that up myself once a proposal is accepted. Very cool development!
Re: Preparing for the New DIP Process
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote: Just wanted to put out a heads up. More to come! I hope the new `'dip'` process is as simple as `writing plugins`.
Preparing for the New DIP Process
A few months back when I announced in one of our planning updates that we were freezing the DIP queue to focus on stabilization, I noted that the DIP process was going to get an overhaul. I've since learned that this message didn't stick, so I'll paste here what I said then. --- The DIP process is getting a long-needed overhaul. Over time, I've had feedback from people who have authored DIPs and those who decided not to. There are a number of different opinions about how things can change, but there are some common themes among them. I'll write in more detail about this later, but there are a few major goals I have with the overhaul: * reduce the burden on the author * reduce the amount of time a submitted DIP is in review * establish support for fleshing out ideas before a DIP is even written * establish support for developing initial DIP drafts before they are submitted Previously, I'd always considered development of the DIP separate from the DIP "process", which I saw as beginning with the submission of a pull request. In reality, the process begins even before an author opens an editor to start typing. I hope that by recognizing that, and by providing support for discussing ideas and writing the DIP, we'll foster an environment that still maintains a relatively high bar for DIPs that get submitted, but also creates a filter such that potential DIP authors can be more confident that they aren't wasting their time once they get to the development stage. By the time they get there, they'll have no doubt if it's an idea worth pursuing. --- I'm getting ready to open things up again. The new process is going to be much, much looser than before. I'll have all the details in the announcement when we reopen, and I should be able to give you a general timeframe after our planning session tomorrow. I'm making this pre-announcement announcement now so that any authors with a DIP frozen in the PR queue can have a heads up. We'll need to treat these somewhat differently than new DIPs, but we'll be ready to get moving on them when the author is. It's entirely on the author's schedule, not ours. And if any of you are thinking about submitting a new DIP, I ask you to start thinking about the details, but don't start writing it just yet. Once the new process is open, you won't have to sit and write it in isolation with no feedback from Walter or Atila. You'll be able to get feedback early from both them and the community, so you can know very early on if it's something you're willing to pursue, and you'll hopefully have a good bit of help to get it developed. The process as it existed had a high bar with the intention of encouraging the production of quality DIPs and discouraging frivolous proposals. In practice, that high bar was a high barrier to entry and ended up discouraging even good proposals. I'm optimistic that the new process will lower the barrier to entry and still encourage quality proposals. And by "quality" I'm not referring to the quality of the DIP's language. In the new process, the focus will be entirely on the details of the proposal and not on the language in which they're presented. I'm happy to clean that up myself once a proposal is accepted. Just wanted to put out a heads up. More to come!
Re: The New New DIP Process
On Friday, 9 March 2018 at 12:59:07 UTC, Mike Parker wrote: When I took on the role of DIP Manager last year, I didn't realize how much I had to learn. Most of the DIPs made it through just fine, but there were a few errors along the way. And there were some inefficiencies built into the system that weren't so obvious in the beginning. Recently, my new procedure document to revise the process was approved. [...] mistake: "for the all the details"
The New New DIP Process
When I took on the role of DIP Manager last year, I didn't realize how much I had to learn. Most of the DIPs made it through just fine, but there were a few errors along the way. And there were some inefficiencies built into the system that weren't so obvious in the beginning. Recently, my new procedure document to revise the process was approved. Structurally, the process is still the same. Now, it has more clearly defined responsibilities and time constraints. Hopefully, this will kill the inefficiencies we identified in the system, and I'll keep an eye open to adapting it as necessary. This blog post summarizes the changes, their motivation, and my new attitude toward the role of the DIP Manager. Blog: https://dlang.org/blog/2018/03/09/the-new-new-dip-process/ Reddit: https://www.reddit.com/r/d_language/comments/836fwt/the_new_new_dip_process/
The Why and Wherefore of the New DIP Process
Dicebot was kind enough to share his thoughts on what motivated him to initiate an overhaul of the DIP process *and* volunteer to act as the DIP manager for the time being [1]. The reddit thread is at [2]. [1] https://dlang.org/blog/2016/07/20/the-why-and-wherefore-of-the-new-d-improvement-proposal-process/ [2] https://www.reddit.com/r/programming/comments/4tr32z/the_why_and_wherefore_of_the_new_d_improvement/
