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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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`
On Saturday, 27 January 2024 at 04:35:11 UTC, Jordan Wilson wrote:
Does Go and Python qualify as serious languages?
Of course not!
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
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
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
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.
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
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
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
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
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.
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
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.
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
> >
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
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!
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
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
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,
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
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!
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!
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
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
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.
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 ,
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.
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
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`
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
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
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.
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
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
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,
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
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
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.
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
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!
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,
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
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.
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,
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
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
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
This is going to be a great initiative. Thanks, Mike!
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
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`.
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
74 matches
Mail list logo
