On Monday, 20 February 2023 at 07:11:49 UTC, Mike Parker wrote:
On Monday, 20 February 2023 at 06:26:34 UTC, FeepingCreature
wrote:
There have now been three pages produced by three people all
agreeing with each other.
At what point does it start being spam?
Yes, it's all just noise now.
On Monday, 20 February 2023 at 06:26:34 UTC, FeepingCreature
wrote:
There have now been three pages produced by three people all
agreeing with each other.
At what point does it start being spam?
Yes, it's all just noise now. Let's end it here. Further posts in
this thread will be deleted
But in any case, it should be class private.
There have now been three pages produced by three people all
agreeing with each other.
At what point does it start being spam?
Having a discussion !== spam.
On Monday, 20 February 2023 at 05:21:44 UTC, forky wrote:
On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:
...
Having class-private doesn't preclude module-private. Dennis
even submitted a PR implementing class-private, but it stalled
because people couldn't agree on whether cl
On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:
...
Having class-private doesn't preclude module-private. Dennis
even submitted a PR implementing class-private, but it stalled
because people couldn't agree on whether class-private should
be "private to class" or "private to cl
On Sunday, 19 February 2023 at 00:21:42 UTC, ProtectAndHide wrote:
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
The more I look at D, the more I like C++.
I should correct that.
The more I look at D, the more I like C++, C#, Java, Kotlin,
Swift, Javascript .. and the
On Sunday, 19 February 2023 at 00:21:42 UTC, ProtectAndHide wrote:
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
The more I look at D, the more I like C++.
I should correct that.
The more I look at D, the more I like C++, C#, Java, Kotlin,
Swift, Javascript .. and the
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
The more I look at D, the more I like C++.
I should correct that.
The more I look at D, the more I like C++, C#, Java, Kotlin,
Swift, Javascript .. and the list goes on..
All D needed to provide, was a way to let the prog
On Saturday, 18 February 2023 at 22:03:48 UTC, Adam D Ruppe wrote:
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
The more I look at D, the more I like C++.
cya
of course, I do have my own fork ;-)
where you CAN declare private members for your class.
and.. where all
On Saturday, 18 February 2023 at 22:03:48 UTC, Adam D Ruppe wrote:
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
The more I look at D, the more I like C++.
cya
I bet that's what you say to anyone who dares want to have hidden
members inside their class.
All the thre
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
The more I look at D, the more I like C++.
cya
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
Here is (one example) of the change I would like to see in D:
if private is declared against a member inside a class (or
struct), then that member is visible only inside that class or
struct. That is what most programmers
On Saturday, 18 February 2023 at 07:49:03 UTC, RTM wrote:
On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide
wrote:
More likely is comes from my experience .. otherwise I
wouldn't be surprised ;-)
Now that's a screaming sign:
https://media.licdn.com/dms/image/C4D12AQEymZALzWVDXQ/
On Saturday, 18 February 2023 at 07:49:03 UTC, RTM wrote:
Implying that D language maintainers should prefer your
personal taste over modern practice?
So it's now modern practice to dump the principle of data hiding?
I'm sure that will surely advance the science of programming.
Don't like
On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide
wrote:
More likely is comes from my experience .. otherwise I wouldn't
be surprised ;-)
Now that's a screaming sign:
https://media.licdn.com/dms/image/C4D12AQEymZALzWVDXQ/article-cover_image-shrink_600_2000/0/1629008577928?e=21474
On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide
wrote:
No, I think D is not for me.
They don't care about the needs of `D` users!
They won't listen ,even if you said it thousand times.
On Saturday, 18 February 2023 at 06:12:47 UTC, RTM wrote:
No offense, but it looks like your surprise comes from your
inexperience.
More likely is comes from my experience .. otherwise I wouldn't
be surprised ;-)
btw.
I love the way that Brayan Martinez (Senior Developer with Azure,
Spr
On Friday, 17 February 2023 at 22:58:19 UTC, ProtectAndHide wrote:
Actually, I just now understand 'why' (as opposed to 'how')
private works in D the way it does.
In D, private within a module is (more-or-less) like static used
in C outside of a function.
That is, in C it restrains the v
On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
Data hiding is overrated.
...
Actually, data hiding is at the core of using objects, and
objects are at the core of doing OOP.
" Hiding internal state and requiring all interaction to be
performed through an object's methods is known
On Friday, 17 February 2023 at 09:56:26 UTC, RTM wrote:
On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide
Thirty years passed since. Lessons were learned. Out of three
PLs of the newer generation (Rust, Swift, Go), two are not OOP,
basically.
And no private/public/protected:
https
Funny, seems I have old news: Rust adopted D-like module
visibility.
https://doc.rust-lang.org/reference/visibility-and-privacy.html
pub(in path), pub(crate), pub(super), and pub(self)
In addition to public and private, Rust allows users to declare
an item as visible only within a given scope
On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide wrote:
What is 'Object-Oriented Programming'? (1991 revised version)
Bjarne Stroustrup
https://www.stroustrup.com/whatis.pdf
Thirty years passed since. Lessons were learned. Out of three PLs
of the newer generation (Rust, Swift, Go
On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
Data hiding is overrated.
Furthermore, OOP is overrated :-)
https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
What is 'Object-Oriented Programming'? (1991 revised version)
Bjarne Stroust
On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:
Data hiding is overrated.
Furthermore, OOP is overrated :-)
https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
Submit a request to the C++ Committee to remove private from the
language.
On Friday, 17 February 2023 at 04:43:11 UTC, RTM wrote:
On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide
wrote:
Both the module type, and the class type need this capability.
No, they are not.
Look at Go.
Go does not have classes.
Data hiding is overrated.
Furthermore, OOP is overrated :-)
https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide
wrote:
Both the module type, and the class type need this capability.
No, they are not.
Look at Go.
On Friday, 17 February 2023 at 01:21:18 UTC, zjh wrote:
They don't admit their mistakes! And `D` community is getting
smaller and smaller!
Because other languages laughs cry!
`D` don't even have `type-safe` classes.
The ability of a group of people to open their eyes and tell lies
is really
On Friday, 17 February 2023 at 01:13:59 UTC, zjh wrote:
They can't refute you, so they have to blame you.
You can't wake up who pretend to sleep.
They don't admit their mistakes! And `D` community is getting
smaller and smaller!
If I were D author , I would suspect that they are undercover
On Thursday, 16 February 2023 at 22:25:22 UTC, ProtectAndHide
wrote:
also, I noticed that you intentionally? did not respond to the
facts that I outlined:
ie.
They can't refute you, so they have to blame you.
You can't wake up who pretend to sleep.
On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote:
On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide
wrote:
Forcing programmers to use a design mechanism rather than a
language mechanism to achieve the above abstraction is wrong.
This seems to be the source of the dis
On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote:
On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide
wrote:
Forcing programmers to use a design mechanism rather than a
language mechanism to achieve the above abstraction is wrong.
This seems to be the source of the dis
On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide
wrote:
Forcing programmers to use a design mechanism rather than a
language mechanism to achieve the above abstraction is wrong.
This seems to be the source of the disagreement, correct?
There's no disagreement. It's you posting t
On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide
wrote:
My agrument is this:
Objects are data abstractions with an interface of named
operations and a hidden local state. Does anyone disagree with
this?
D does not have a language mechanism, but rather a design
mechanism that
On Thursday, 16 February 2023 at 13:39:13 UTC, H. S. Teoh wrote:
On Thu, Feb 16, 2023 at 08:51:39AM +, FeepingCreature via
Digitalmars-d-learn wrote: [...]
Springboarding off this post:
This thread is vastly dominated by some people who care very
much about this issue. Comparatively, for i
On Thu, Feb 16, 2023 at 08:51:39AM +, FeepingCreature via
Digitalmars-d-learn wrote:
[...]
> Springboarding off this post:
>
> This thread is vastly dominated by some people who care very much
> about this issue. Comparatively, for instance, I care very little
> because I think D already does
So let me just say: I think D does it right. D does not have
class encapsulation; it has module encapsulation. This is by
design, and the design is good.
The design is terrible...
On Thursday, 16 February 2023 at 02:27:23 UTC, Mike Parker wrote:
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker
wrote:
Wrong. I'm arguing things:
Geez. "I'm arguing 2 things:"
Springboarding off this post:
This thread is vastly dominated by some people who care very much
ab
But at stop mispresenting what I'm saying. What I've stated
above, is what I'm saying.. no more.. no less.
Well said.
Its not that hard to understand, folks.
On Wednesday, 15 February 2023 at 12:44:19 UTC, zjh wrote:
Right... They greatly increase your code maintenance work!
Many people left D because of these small details!
Their encapsulation can actually leakage class members.
Programmers in other languages will laugh cry!
On Thursday, 16 February 2023 at 02:56:28 UTC, ProtectAndHide
wrote:
What a joke. Even Javascript can do this (and the compile will
enforce it too).
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide
wrote:
What Mike is arguing, is that I don't need a 'data hiding'
mechanism for a user-defined type, because that is already
provided to me by the 'data hiding' m
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide
wrote:
What Mike is arguing, is that I don't need a 'data hiding'
mechanism for a user-defined type, because that is already
provided to me by the 'data hiding' m
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
Wrong. I'm arguing things:
Geez. "I'm arguing 2 things:"
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide
wrote:
What Mike is arguing, is that I don't need a 'data hiding'
mechanism for a user-defined type, because that is already
provided to me by the 'data hiding' mechanism of the module.
That is his argument.
My argument is tha
On Wednesday, 15 February 2023 at 20:34:13 UTC, thebluepandabear
wrote:
On Wednesday, 15 February 2023 at 20:06:18 UTC, bachmeier wrote:
On Wednesday, 15 February 2023 at 07:13:41 UTC,
thebluepandabear wrote:
Time to move on to OCaml programmers telling us D doesn't
have floating point arithmet
On Wednesday, 15 February 2023 at 20:06:18 UTC, bachmeier wrote:
On Wednesday, 15 February 2023 at 07:13:41 UTC,
thebluepandabear wrote:
Time to move on to OCaml programmers telling us D doesn't
have floating point arithmetic because there's no `+.`
operator.
that's not the same thing though,
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide
wrote:
...
this is not to be personal, just to make an analogy about the
point being made:
if Mike was a car salesperson, he'd be arguing that I don't need
an automatic transmission. I can already do it manually. Why
should we
On Wednesday, 15 February 2023 at 20:01:12 UTC, bachmeier wrote:
On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide
wrote:
A user-defined type is a type that has a mechanism to keep it
representation private.
D does not support this. It only enables it.
You (and others) may well
On Wednesday, 15 February 2023 at 07:13:41 UTC, thebluepandabear
wrote:
Time to move on to OCaml programmers telling us D doesn't have
floating point arithmetic because there's no `+.` operator.
that's not the same thing though, you've created a great false
equivalence! Congrats.
Only if you
On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide
wrote:
"The basic support for programming with data abstraction consists
of facilities for defining a set of operations (functions and
operators) for a type and for restricting the access to objects
of the type to that set of op
On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide
wrote:
A user-defined type is a type that has a mechanism to keep it
representation private.
D does not support this. It only enables it.
You (and others) may well argue that D should not enable this
(directly), it should only s
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
I referenced that in my post. The exact same problem exists
*inside* the class when your class file is very long. You can
easily manipulate the private member even when it's only
supposed to be accessed by a specific function.
On Wednesday, 15 February 2023 at 09:57:56 UTC, ProtectAndHide
wrote:
In a module that contains a class, and other code as well
(perhaps other tightly coupled classes), you can know
**nothing** at all about that type (or any other class) without
knowing **everything** else in the module. If o
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote:
Our friend of many forum handles misses no opportunity to
return to this putrid horse corpse to beat it some more, but
the meaning of private isn't going to change. This is D's
approach to encapsulation.
It seems the only be
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote:
Our friend of many forum handles misses no opportunity to
return to this putrid horse corpse to beat it some more, but
the meaning of private isn't going to change. This is D's
approach to encapsulation.
It seems the only be
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
We keep repeating the same arguments over and over and over
again on this. I still haven't seen any convincing argument for
changing things when it's already possible to do what you want
to do. I repeat for the umpteenth time:
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
I referenced that in my post. The exact same problem exists
*inside* the class when your class file is very long. You can
easily manipulate the private member even when it's only
supposed to be accessed by a specific function.
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote:
What if two classes in the module that are several meters apart
make `mistakes` that change the privite variable of `another
class`?
No one can guarantee that after `a few months`, even if you are
the author, you will not make mist
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote:
On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker
wrote:
I meant to say, it "wouldn't add more".
What if two classes in the module that are several meters apart
make `mistakes` that change the privite variable of `another
On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear
wrote:
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker
wrote:
On Wednesday, 15 February 2023 at 01:16:00 UTC,
thebluepandabear wrote:
I think what you could say is that D lacks _encapsulation_
which is also an OOP
On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote:
I meant to say, it "wouldn't add more".
What if two classes in the module that are several meters apart
make `mistakes` that change the privite variable of `another
class`?
No one can guarantee that after `a few months`, e
On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker
wrote:
If private were restricted to the class/struct, it would add
anything more for encapsulation in D.
I meant to say, it "wouldn't add more".
Well, to quote St
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote:
If private were restricted to the class/struct, it would add
anything more for encapsulation in D.
I meant to say, it "wouldn't add more".
On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear
wrote:
Why is the unit of encapsulation the module though? Makes no
sense.
What is the purpose of encapsulation? To keep the implementation
details hidden behind the public API, such that changing the
implementation doesn't
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 01:16:00 UTC,
thebluepandabear wrote:
I think what you could say is that D lacks _encapsulation_
which is also an OOP concept. So D is partially OOP but not
fully OOP due to there being no e
Time to move on to OCaml programmers telling us D doesn't have
floating point arithmetic because there's no `+.` operator.
that's not the same thing though, you've created a great false
equivalence! Congrats.
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 01:16:00 UTC,
thebluepandabear wrote:
I think what you could say is that D lacks _encapsulation_
which is also an OOP concept. So D is partially OOP but not
fully OOP due to there being no e
On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear
wrote:
I think what you could say is that D lacks _encapsulation_
which is also an OOP concept. So D is partially OOP but not
fully OOP due to there being no encapsulation in the language.
D does not lack encapsulation, it's
On Wednesday, 15 February 2023 at 01:15:09 UTC, thebluepandabear
wrote:
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide
wrote:
In any case, there is nothing 'picky' about wanting to be
able to explicately 'declare' a
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide
wrote:
In any case, there is nothing 'picky' about wanting to be able
to explicately 'declare' a member of my class type as being
private. That to me, is what a programm
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide
wrote:
In any case, there is nothing 'picky' about wanting to be able
to explicately 'declare' a member of my class type as being
private. That to me, is what a programm
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide
wrote:
In any case, there is nothing 'picky' about wanting to be able
to explicately 'declare' a member of my class type as being
private. That to me, is what a programmer should expect to be
able to do in a language that says it su
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide
wrote:
On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote:
My point is you know you're just picky.
Well.. it seems to me, that your 'point' is to just have a go
at me.
In any case, there is nothing 'picky' about wanting t
On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote:
My point is you know you're just picky.
Well.. it seems to me, that your 'point' is to just have a go at
me.
In any case, there is nothing 'picky' about wanting to be able to
explicately 'declare' a member of my class type as bein
My point is you know you're just picky.
On Monday, 13 February 2023 at 09:14:18 UTC, Kagamin wrote:
On Monday, 13 February 2023 at 08:22:06 UTC, ProtectAndHide
wrote:
Chris Lattner outlines the reasons for removing it in Swift
3.0 here:
https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.m
On Monday, 13 February 2023 at 08:22:06 UTC, ProtectAndHide wrote:
Chris Lattner outlines the reasons for removing it in Swift 3.0
here:
https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md
So your complaint is that you agree with Chris Lattner an
On Monday, 13 February 2023 at 07:19:49 UTC, Kagamin wrote:
On Friday, 10 February 2023 at 21:52:02 UTC, ProtectAndHide
wrote:
Well in Swift, there is no problem .. at all.
Why is it a problem in D then? (and I mean technically).
What about the increment operator `++` ?
Remember, that a one
On Friday, 10 February 2023 at 21:52:02 UTC, ProtectAndHide wrote:
Well in Swift, there is no problem .. at all.
Why is it a problem in D then? (and I mean technically).
What about the increment operator `++` ?
For a language that claims to supprot OOP, and does public by
default, and no way to declare type private... I mean... wow!
agree, it should definitely be `private` by default... if
`private` was implemented properly lmao
On Saturday, 11 February 2023 at 02:17:09 UTC, thebluepandabear
wrote:
I'm not an advocate of any style in particular. I'm happy to
use any style that is clear to understand and use, suitable,
and can provide reasonable guarantees around memory safety and
correctness.
But a language that clai
gh in my
opinion. i've never seen a usecase for it in an object oriented
language. Of course Kotlin can do this, which is good, but you
can just create utility classes (i.e. `static class` in C#,
`final class` in Java with a private ctor, or Kotlin `object`.)
Yes, it's overrated, I ag
On Saturday, 11 February 2023 at 02:15:37 UTC, thebluepandabear
wrote:
That's not entirely correct.
I don't use any Apple hardware products. Never have, and never
will.
I use Swift on Linux only.
There are of course some library features of Swift tied to
Apple products. But I have no need f
t oriented language.
Of course Kotlin can do this, which is good, but you can just
create utility classes (i.e. `static class` in C#, `final class`
in Java with a private ctor, or Kotlin `object`.)
That's not entirely correct.
I don't use any Apple hardware products. Never have, and never
will.
I use Swift on Linux only.
There are of course some library features of Swift tied to
Apple products. But I have no need for those library features.
As a standalone language, Swift can (IMO) a
I'm not an advocate of any style in particular. I'm happy to
use any style that is clear to understand and use, suitable,
and can provide reasonable guarantees around memory safety and
correctness.
But a language that claims to support OOP but doesn't even have
type privacy, is a bit of joke
On Friday, 10 February 2023 at 02:57:42 UTC, zjh wrote:
On Friday, 10 February 2023 at 02:04:06 UTC, ProtectAndHide
wrote:
"Before practicing Zen, mountains were mountains and rivers
were rivers.
While practicing Zen, mountains are no longer mountains and
rivers are no longer rivers.
After re
On Friday, 10 February 2023 at 23:24:11 UTC, thebluepandabear
wrote:
I think the 'real' problem, is that some core D people just
refuse to allow D to provide such an option to the programmer.
I think a lot of it has to do with the fact that heaps of D
programmers write procedural code and don
On Friday, 10 February 2023 at 23:22:34 UTC, thebluepandabear
wrote:
A good example of a language that does everything right is C#.
If C# wasn't tied to Microsoft, it would honestly be pretty
much the perfect language. Java is also pretty good, but it has
its downsides.
I don't agree with all
On Friday, 10 February 2023 at 23:19:31 UTC, thebluepandabear
wrote:
I think the 'real' problem, is that some core D people just
refuse to allow D to provide such an option to the programmer.
For what reason, I cannot fathom, since Swift can do this just
fine. I think it's some kind of bias aga
I think the 'real' problem, is that some core D people just
refuse to allow D to provide such an option to the programmer.
I think a lot of it has to do with the fact that heaps of D
programmers write procedural code and don't care about any object
oriented features, that's because they're 'o
A good example of a language that does everything right is C#. If
C# wasn't tied to Microsoft, it would honestly be pretty much the
perfect language. Java is also pretty good, but it has its
downsides.
I think the 'real' problem, is that some core D people just
refuse to allow D to provide such an option to the programmer.
For what reason, I cannot fathom, since Swift can do this just
fine. I think it's some kind of bias against a particular style
of programming that some don't want to see oc
On Friday, 10 February 2023 at 14:50:59 UTC, bachmeier wrote:
On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:
Having class-private doesn't preclude module-private. Dennis
even submitted a PR implementing class-private, but it stalled
because people couldn't agree on whether cla
On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:
Having class-private doesn't preclude module-private. Dennis
even submitted a PR implementing class-private, but it stalled
because people couldn't agree on whether class-private should
be "private to class" or "private to class i
On Friday, 10 February 2023 at 14:17:25 UTC, Kagamin wrote:
Pretty sure you can strip namespaces in any language that has
namespaces, C# routinely does it and refers to all types with
their nonqualified names. It even has Keys enum:
https://learn.microsoft.com/en-us/dotnet/api/system.windows.fo
On Monday, 23 January 2023 at 00:36:36 UTC, thebluepandabear
wrote:
It's not a freedom issue, it's a library-design issue. Some
libraries want to incorporate a namespace-like design to force
the user to be more 'explicit' with what they want.
SFML has a `Keyboard` namespace which has a `Key` e
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:
Besides, D has zero problems with its private implementation in
the sense that there has been zero bugs related to it being
that way.
That is how a Python aficionado would defend the absence of
visibility attributes therein. "W
On Friday, 10 February 2023 at 02:04:06 UTC, ProtectAndHide wrote:
"Before practicing Zen, mountains were mountains and rivers
were rivers.
While practicing Zen, mountains are no longer mountains and
rivers are no longer rivers.
After realization, mountains are mountains and rivers are
rivers
1 - 100 of 282 matches
Mail list logo
