On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer
wrote:
unittest
{
auto foo = new Foo;
assert(foo.internalbuffer.empty); // note, this is a private
symbol.
}
I don't understand why you would want a private symbol in a
*documented* unittest, the reader of the *documentatio
On Monday, 19 March 2018 at 01:11:43 UTC, psychoticRabbit wrote:
The fact that the creator of a class, is also the creator of
the module that contains that class, is not a valid reason for
not seeking to improve encapsulation of that class.
I agree with this. This especially matters with proje
On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer
wrote:
If we could go back in time and talk with a young Walter about
the consequences of choosing the scheme the way it is, maybe he
might have made different choices, but at this point, it's hard
to change it.
I think this h
On Sunday, 18 March 2018 at 11:12:46 UTC, Alex wrote:
´´´
Are there any scenarios in which the person writing the class,
would want to encapsulate their class, or some parts of it,
from the rest of a module (while being forced to put the class
in this module)?
´´´
The answer is no. As the p
On Sunday, 18 March 2018 at 18:04:13 UTC, Tony wrote:
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
D is not C++, C#, or Java. C++ uses friend to get around the
issue. Java has no solution. I don't know about C#.
Java has four protection levels. If you don't explicitly
sp
On Sunday, March 18, 2018 18:59:39 Tony via Digitalmars-d-learn wrote:
> On Sunday, 18 March 2018 at 18:32:42 UTC, Jonathan M Davis wrote:
> > They're similar, but there are differences. For instance, you
> > can do package(a) in D in order to do something like put the
> > stuff in a.b.c in package
On Sunday, 18 March 2018 at 18:32:42 UTC, Jonathan M Davis wrote:
They're similar, but there are differences. For instance, you
can do package(a) in D in order to do something like put the
stuff in a.b.c in package a rather than a.b.
Is there a known situation where it makes sense to put mo
On 3/17/18 5:56 AM, Nick Treleaven wrote:
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer wrote:
If you limit to class members, then you have to do something like C++
friends, which are unnecessarily verbose.
Not if you also have a module-level visibility modifier, which could
On Sunday, March 18, 2018 18:04:13 Tony via Digitalmars-d-learn wrote:
> On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
> > D is not C++, C#, or Java. C++ uses friend to get around the
> > issue. Java has no solution. I don't know about C#.
>
> Java has four protection levels. If you
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
D is not C++, C#, or Java. C++ uses friend to get around the
issue. Java has no solution. I don't know about C#.
Java has four protection levels. If you don't explicitly specify
[private, protected, public] the protection level
On Sunday, 18 March 2018 at 10:45:55 UTC, psychoticRabbit wrote:
On Sunday, 18 March 2018 at 10:14:30 UTC, Alain Soap wrote:
[...]
" Private - All fields and methods that are in a private block,
can only be accessed in the module (i.e. unit) that contains
the class definition. They can be ac
On Sunday, 18 March 2018 at 09:56:31 UTC, psychoticRabbit wrote:
However, are there no scenarios in which the person writing
that module, would not want to encapsulate their class, or some
parts of it, from the rest of the module (while not being
forced to put the class in it's own file)?
If
On Sunday, 18 March 2018 at 10:14:30 UTC, Alain Soap wrote:
BTW i think adding this can be useful. The FreePascal language
has `strict private` for example.
" Private - All fields and methods that are in a private block,
can only be accessed in the module (i.e. unit) that contains the
class d
On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote:
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote:
On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:
maybe extend that to a list of types?
this is basically what C++ friend does and D was trying to
avoid
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote:
The fact is, the creator of the class is also the creator of
the module.. and preventing him from having full access to the
class is ignorant. He doesn't need to encapsulate himself.
Encapsulation is ONLY meant to reduce dependenci
On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote:
In D, I would prefer no breaking change here. Leave private as
it is.
My suggestion has no breaking change and it works just like the
package attribute already works.
Also you shouldn't allow multiple types for it, that would
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote:
Why do you insist that you know how everything works and you
are the harbinger of truth. The fact is, you don't know squat
about what you are talking about and you just want to conform D
to your naive ignorant ...etc...etc..etc
On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote:
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote:
On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:
maybe extend that to a list of types?
this is basically what C++ friend does and D was trying to
avoid
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote:
On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:
maybe extend that to a list of types?
this is basically what C++ friend does and D was trying to
avoid the complexity of
Really, the complexity of 'friend' comes from p
On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:
maybe extend that to a list of types?
this is basically what C++ friend does and D was trying to avoid
the complexity of
On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote:
I don't like the name @deny, personally I would rather see the
private attribute changed to something like:
private(true) // The member is oly visible to its parent.
private(false) // Same as just "private", visible to whole
module.
C
On Saturday, 17 March 2018 at 15:02:21 UTC, psychoticRabbit wrote:
On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote:
I don't like the name @deny .
how about:
@reallyis private string firstName_;
mmm..perhaps not... then how about...
@strictly private string firstName_;
Still i
On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote:
I don't like the name @deny .
how about:
@reallyis private string firstName_;
mmm..perhaps not... then how about...
@strictly private string firstName_;
On Saturday, 17 March 2018 at 11:08:27 UTC, psychoticRabbit wrote:
On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven
wrote:
It's a language design decision as to whether a particular
feature is worth supporting. I would like this feature too
though. I'm not sure how much compiler compl
On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven wrote:
It's a language design decision as to whether a particular
feature is worth supporting. I would like this feature too
though. I'm not sure how much compiler complexity would be
added by having another visibility modifier.
D c
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer
wrote:
If you limit to class members, then you have to do something
like C++ friends, which are unnecessarily verbose.
Not if you also have a module-level visibility modifier, which
could have been `module`.
IMO, the module-leve
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
If you have access to the module source, you have access to
the source of types inside it. Making the module the lowest
level of encapsulation makes sense from that perspective.
There are two problems I see:
1st - D has broken
On Tuesday, 13 March 2018 at 22:56:31 UTC, Jonathan M Davis wrote:
The downside is that it increases the number of symbols which
the program has to deal with when linking against a shared
library, which can have some negative effects.
- Jonathan M Davis
If I understand correctly it's also re
On Wednesday, 14 March 2018 at 04:30:17 UTC, Amorphorious wrote:
On Wednesday, 14 March 2018 at 01:41:33 UTC, psychoticRabbit
wrote:
On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote:
You are a moron...etc..etc..etc..etc.
See. This is what happens when you have acces
On Wednesday, 14 March 2018 at 01:41:33 UTC, psychoticRabbit
wrote:
On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote:
You are a moron...etc..etc..etc..etc.
See. This is what happens when you have access to a keyboard
while high on ice.
Yep. So maybe you should sto
On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote:
You are a moron...etc..etc..etc..etc.
See. This is what happens when you have access to a keyboard
while high on ice.
On Tuesday, March 13, 2018 22:25:52 Nathan S. via Digitalmars-d-learn wrote:
> On Tuesday, 13 March 2018 at 21:36:13 UTC, Arun Chandrasekaran
>
> wrote:
> > On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer
> >
> > wrote:
> >> On 3/12/18 10:06 PM, psychoticRabbit wrote:
> >>> [...]
>
On Tuesday, 13 March 2018 at 21:36:13 UTC, Arun Chandrasekaran
wrote:
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer
wrote:
On 3/12/18 10:06 PM, psychoticRabbit wrote:
[...]
OK, so I agree there are drawbacks. But these can be worked
around.
[...]
Private members still h
On Tuesday, March 13, 2018 21:36:13 Arun Chandrasekaran via Digitalmars-d-
learn wrote:
> On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer
>
> wrote:
> > On 3/12/18 10:06 PM, psychoticRabbit wrote:
> >> [...]
> >
> > OK, so I agree there are drawbacks. But these can be worked
> > aro
On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote:
what I don't like, is that I have no way at all to protect
members of my class, from things in the module, without moving
that class out of that module.
D wants me to completely trust the module, no matter what.
That's make a l
On Tuesday, 13 March 2018 at 06:10:26 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote:
There is another problem:
3rd: You are a brainwashed monkey who can't think for himself.
Gee..takes some real brains to come up with that one.
See, You learned a
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer
wrote:
On 3/12/18 10:06 PM, psychoticRabbit wrote:
[...]
OK, so I agree there are drawbacks. But these can be worked
around.
[...]
Private members still have external linkage. Is there anyway to
solve this?
On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis
wrote:
private is private to the module, not the class. There is no
way in D to restrict the rest of the module from accessing the
members of a class. This simplificat
On 3/12/18 10:06 PM, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
private is private to the module, not the class. There is no way in D
to restrict the rest of the module from accessing the members of a
class. This simplification makes it so that s
On Tuesday, March 13, 2018 02:06:57 psychoticRabbit via Digitalmars-d-learn
wrote:
> On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
> > private is private to the module, not the class. There is no
> > way in D to restrict the rest of the module from accessing the
> > members of
On Tuesday, 13 March 2018 at 13:08:44 UTC, psychoticRabbit wrote:
It also means the author of the class is no longer free to make
changes, because all the surrounding code in the module needs
to be assessed for impact - this greatly increases the burden
of program correctness and maintenance.
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote:
Making modules the lowest level of encapsulation does that
without the need for an extra keyword for friends while still
maintaining a strict border between external and internal APIs.
Moreover, it restricts friends to the same modul
On Tuesday, 13 March 2018 at 12:10:07 UTC, rikki cattermole wrote:
On 14/03/2018 1:02 AM, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole
wrote:
Ah yes.
You're completely correct if you subscribe to Adam's and
ketmar's file sizes expectation.
A D module an
On 14/03/2018 1:02 AM, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote:
Ah yes.
You're completely correct if you subscribe to Adam's and ketmar's file
sizes expectation.
A D module and package is one level of abstraction. If that level of
abstraction
On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote:
Ah yes.
You're completely correct if you subscribe to Adam's and
ketmar's file sizes expectation.
A D module and package is one level of abstraction. If that
level of abstraction starts to fill up and gets large, you
split i
On 14/03/2018 12:19 AM, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassM
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote:
Moreover, it restricts friends to the same module, easing the
maintenance burden and decreasing the chance of error. It was a
great decision.
But, a module can contain so many 'friends'.
Q. How many 'friends' does it take, before y
On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
System.out.println(c.myPri
On Tuesday, 13 March 2018 at 09:52:06 UTC, Mike Parker wrote:
On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit
wrote:
That's make a little uncomfortable, given how long and complex
modules can easily become(and aleady are)
Is there a practical difference between a) a module that
On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote:
That's make a little uncomfortable, given how long and complex
modules can easily become(and aleady are)
Is there a practical difference between a) a module that contains
a class with 20 member functions all accessing private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote:
Any new keywords, or reuse of existing keywords, does make the
language more complex. Everything that is added must have a
reason. Private is module level because friend is so common in
C++, i.e. people find it useful and it would
On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote:
What you're saying, is in D, class encapsulation is really
'module' encapsulation.
I get it. Fine. It's an intersting design decision.
"Enapsulation" in D means the same as it does in every other
language -- hidden from the
On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
I think it's a great feature and I use it frequently. It's
allows more flexibility in class design. Without it, we'd need
another protection attribute to enable the
On Tuesday, 13 March 2018 at 07:39:04 UTC, psychoticRabbit wrote:
I don't have any objection to the idea that a module can have
privileged access to members of classes within that model. It
sounds sensible enough, if the module is a level of
encapsulation also.
My arguments is that, this wa
On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
I think it's a great feature and I use it frequently. It's
allows more flexibility in class design. Without it, we'd need
another protection attribute to enable the
On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
The same applies here. Encapsulation simply isn't broken by
this feature.
What you're saying, is in D, class encapsulation is really
'module' encapsulation.
I ge
psychoticRabbit wrote:
Whatever happened to the 'discussion' component of these 'discussions'?
dunno. try to ask yourself, why repeating the same point again and again
when you were given the answer and the rationale doesn't make a good
discussion.
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
I think it's a great feature and I use it frequently. It's
allows more flexibility in class design. Without it, we'd need
another protection attribute to enable the concept of "private
to the module".
what about a new access at
On Tuesday, 13 March 2018 at 07:05:48 UTC, rikki cattermole wrote:
Your thought model is much younger than modules. Modules have
existed since the mid 70's.
They work, other designs over the years have proven to have
faults and problems.
D's design is evolved from already existing ideas to try
On Tuesday, 13 March 2018 at 06:43:55 UTC, ketmar wrote:
that is, we should stick to defective design only 'cause there
is no "other D" that made it right? ;-)
also, your question is not valid. you were told several times
that you're evaluating the whole thing wrong, but you're
insisting on
Your thought model is much younger than modules. Modules have existed
since the mid 70's.
They work, other designs over the years have proven to have faults and
problems.
D's design is evolved from already existing ideas to try and give the
best of both worlds and modules is no different.
Th
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
The same applies here. Encapsulation simply isn't broken by
this feature.
What you're saying, is in D, class encapsulation is really
'module' encapsulation.
I get it. Fine. It's an intersting design decision.
But, in doing that
psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote:
psychoticRabbit wrote:
So the 3 most used languages got it wrong??
yes.
do you know any other language, where a private class memeber, is not
private to the class?
(btw. that's a question, not a statement).
On Tuesday, 13 March 2018 at 06:26:13 UTC, Radu wrote:
On Tuesday, 13 March 2018 at 06:14:49 UTC, psychoticRabbit
wrote:
On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote:
ah, yes, sorry: i completely forgot that C++ was invented
after c# and java. mea maxima culpa!
My point was, that
On 13/03/2018 7:14 PM, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote:
ah, yes, sorry: i completely forgot that C++ was invented after c# and
java. mea maxima culpa!
My point was, that the 2 most widely used and popular languages on the
plant, C# and Java, de
psychoticRabbit wrote:
So the 3 most used languages got it wrong??
yes.
On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote:
psychoticRabbit wrote:
So the 3 most used languages got it wrong??
yes.
do you know any other language, where a private class memeber, is
not private to the class?
(btw. that's a question, not a statement).
On Tuesday, 13 March 2018 at 06:14:49 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote:
ah, yes, sorry: i completely forgot that C++ was invented
after c# and java. mea maxima culpa!
My point was, that the 2 most widely used and popular languages
on the pl
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
I think it's a great feature and I use it frequently. It's
allows more flexibility in class design. Without it, we'd need
another protection attribute to enable the concept of "private
to the module".
That's kind of my point. That'
On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote:
There is another problem:
3rd: You are a brainwashed monkey who can't think for himself.
Gee..takes some real brains to come up with that one.
See, You learned a little about C++/C#/Java and think the world
must conform to what
On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote:
ah, yes, sorry: i completely forgot that C++ was invented after
c# and java. mea maxima culpa!
My point was, that the 2 most widely used and popular languages
on the plant, C# and Java, decided NOT to make private, something
mean else
psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote:
psychoticRabbit wrote:
There are two problems I see:
1) it is not how C++ done it.
2) it is not how C++ done it.
and you're completely right: it is not how C++ done it.
umm...didn't you forget something:
1) i
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
1st - D has broken the concept of class encapsulation, simply
for convenience at the module level. Not good in my opinion.
No, it hasn't broken encapsulation. Encapsulation is at the
module level. A class or struct and any su
On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote:
psychoticRabbit wrote:
There are two problems I see:
1) it is not how C++ done it.
2) it is not how C++ done it.
and you're completely right: it is not how C++ done it.
umm...didn't you forget something:
1) it is not how C# done it.
psychoticRabbit wrote:
There are two problems I see:
1) it is not how C++ done it.
2) it is not how C++ done it.
and you're completely right: it is not how C++ done it.
On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote:
There is another problem:
3rd: You are a brainwashed monkey who can't think for himself.
No need for personal attacks. Let's keep it civil.
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote:
On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit
wrote:
Mmm.. I don't think I like it.
I feel you should be able to make a member of a class,
private, reg
On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote:
On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit
wrote:
Mmm.. I don't think I like it.
I feel you should be able to make a member of a class,
private, regardless of where the class is located. This seems
to break the con
psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
private is private to the module, not the class. There is no way in D to
restrict the rest of the module from accessing the members of a class.
This simplification makes it so that stuff like C++'s frie
On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote:
Mmm.. I don't think I like it.
I feel you should be able to make a member of a class, private,
regardless of where the class is located. This seems to break
the concept of class encapsulation.
No. I don't like it at all.
If
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote:
private is private to the module, not the class. There is no
way in D to restrict the rest of the module from accessing the
members of a class. This simplification makes it so that stuff
like C++'s friend are unnecessary. If y
On Tuesday, March 13, 2018 01:12:15 psychoticRabbit via Digitalmars-d-learn
wrote:
> I cannot get my head around, why private is not private, in D.
>
> How do I make a private member, private?
>
> -
> module test;
>
> import std.stdio;
>
> void main()
> {
> myClass c = new myClass();
>
Visibility modifiers in D are for the module, not class or struct.
This is very useful to be able to access internal stuff outside of the
abstraction and modify it sanely. While also keeping others at bay.
83 matches
Mail list logo
