On Wednesday, 23 May 2018 at 02:23:31 UTC, Bjarne Stroustrup
wrote:
This is NOT why I created C++ - just so you programmers could
violate an objects autonomy!
So why did you create C++?
On the serious side though, unencapsulated software is
inflexible, and as a result, not very robust.
On Wednesday, 23 May 2018 at 02:23:31 UTC, Bjarne Stroustrup
wrote:
This is NOT why I created C++
You are not Bjarne Stroustrup and you certainly did not created
C++.
On Wednesday, 23 May 2018 at 02:23:31 UTC, Bjarne Stroustrup
wrote:
This is NOT why I created C++ - just so you programmers could
violate an objects autonomy!
No other type gets treated this way in D.
Good on you Bjarne. Someone has to stick up for the class.
We're with you Bjarne.
While
On Tuesday, 22 May 2018 at 13:33:12 UTC, 12345swordy wrote:
On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup
wrote:
Any debate about restoring the rights and autonomy of the
class, should not be killed off.
Any programming language that discriminates against the class,
encourages
On Tuesday, 22 May 2018 at 13:33:12 UTC, 12345swordy wrote:
On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup
wrote:
Any debate about restoring the rights and autonomy of the
class, should not be killed off.
Any programming language that discriminates against the class,
encourages
On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote:
Any debate about restoring the rights and autonomy of the
class, should not be killed off.
Any programming language that discriminates against the class,
encourages class warfare, does not deserve to be called a
programming
On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
This hypotetical unittest is testing a hypotetical class in a
hypotetical module with hypotetical properties.
Why is it outside the class? I don't know, maybe it needs
access to two classes which are defined in thesame module. But
On Tuesday, 22 May 2018 at 07:34:24 UTC, bauss wrote:
I cannot take you seriously when all you do is spread
misinformation and invalid statistics.
Don't under-estimate, the power of misinformation and invalid
statistics.
After all, if both can help you become supreme leader of the
worlds
On Monday, 21 May 2018 at 03:19:34 UTC, KingJoffrey wrote:
18+ years, and still less than 1000 programmers.
What kind of misinformation is that?
vibe.d alone has over 2000 downloads per week and I'll mind you
that regular users of vibe.d does not download or update the
package that often.
On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote:
Any debate about restoring the rights and autonomy of the
class, should not be killed off.
Any programming language that discriminates against the class,
encourages class warfare, does not deserve to be called a
programming
On Monday, 21 May 2018 at 19:51:38 UTC, Andrei Alexandrescu wrote:
Hi folks, it looks like at least a few branches of this thread
have run well past their useful course and into tedious
territory.
We don't like to go about killing threads, so we kindly ask
that you all refrain from posting
On Monday, 21 May 2018 at 19:51:38 UTC, Andrei Alexandrescu wrote:
Hi folks, it looks like at least a few branches of this thread
have run well past their useful course and into tedious
territory.
We don't like to go about killing threads, so we kindly ask
that you all refrain from posting
Hi folks, it looks like at least a few branches of this thread have run
well past their useful course and into tedious territory.
We don't like to go about killing threads, so we kindly ask that you all
refrain from posting in this thread going forward.
Thanks much!
Andrei
On Monday, 21 May 2018 at 15:30:40 UTC, Gheorghe Gabriel wrote:
On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote:
My suggestions are about resolving this, in order to attract
more programmers to D, because I doubt I'm the only person in
the world, that believes an object has a right
On Monday, 21 May 2018 at 16:35:57 UTC, rikki cattermole wrote:
Please stop replying Dave, it isn't worth it.
Do something more productive with your time :)
I know, but... it helps me relax. ;-)
Please stop replying Dave, it isn't worth it.
Do something more productive with your time :)
On Monday, 21 May 2018 at 14:54:57 UTC, KingJoffrey wrote:
On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
Also, I would verry much much like it if you would not resort
to comparing me to "one of those facebook employees." It's
just setting a mood for the conversation which no
On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote:
On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:
da dah dah
da dah dah dahh da d
..
.
... da dah..
..da..
da ...dadada.da...dada.
Thanks Dave.
Your contributions to the discussion
On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote:
My suggestions are about resolving this, in order to attract
more programmers to D, because I doubt I'm the only person in
the world, that believes an object has a right to privacy.
Of course you are not the only person that believes
On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
Nope, I'm simply a bystander who sees lack of class scope as a
"feature" of D that is usefull in some cases while not hurting
idiomatic OOP as long as you only define a single class (+
unittests) inside a module.
If you want that
On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
Also, I would verry much much like it if you would not resort
to comparing me to "one of those facebook employees." It's just
setting a mood for the conversation which no one likes,
regardless what anyone thinks about facebook
On Monday, 21 May 2018 at 14:30:21 UTC, KingJoffrey wrote:
On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:
While you might say that a unittest shouldn't acces private
members and only public members, there are plenty of testcases
where one would want to write a unittest to set
On Monday, 21 May 2018 at 13:36:32 UTC, 12345swordy wrote:
If you resort to mockery, then that means you have lost the
argument.
I prefer to think of it as sarcasm, not mockery.
Sarcasm is a form of intelligent expression, to wield however you
see fit
(not unlike a module in D ;-)
For
On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:
While you might say that a unittest shouldn't acces private
members and only public members, there are plenty of testcases
where one would want to write a unittest to set a given
variable via public function and then test if the
On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote:
On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:
da dah dah
da dah dah dahh da d
..
.
... da dah..
..da..
da ...dadada.da...dada.
Thanks Dave.
Your contributions to the discussion
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
class A {
private int x;
private(this) int y;
}
Instead of such a syntax if this ever comes to be, we could just
introduce a new keyword into the language.
class A {
private int x;
closed int y; //closed for acces outside
On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:
da dah dah
da dah dah dahh da d
..
.
... da dah..
..da..
da ...dadada.da...dada.
Thanks Dave.
Your contributions to the discussion have been really insightful,
and most valuable.
I'm sure we
On Monday, 21 May 2018 at 03:19:34 UTC, KingJoffrey wrote:
On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:
On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel
wrote:
Anyway... feel free to misrepresent what I've said,
On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:
I wouldn't consider putting classes into own modules a
workaround. In my opinion it's more or less the solution.
I'll add your solution into my article - but, I'm not sure it
really addresses my problem statement.
The Problem
On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:
On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel
wrote:
But in D, everything is your friend - you don't get to manage
You want to be taken seriously and yet you
On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel
wrote:
But in D, everything is your friend - you don't get to manage
You want to be taken seriously and yet you repeat false
statements over and over again.
There is
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:
If you have
sealed class A {
private {
// members
}
}
Then you can't use the defualt 'private' if you need it for a
specific member.
But if sealed is an access type of a member, 99% you will use
sealed insted
On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:
On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
If class level protection is added, please do not call it
sealed.
People from c++ might be suprised by 'private' already. We do
not have to confuse those c#ies too.
I thought the
On Saturday, 19 May 2018 at 17:15:45 UTC, Neia Neutuladh wrote:
On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:
The point was encapsulation as you defined it was broken.
private members were directly modified outside their
On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
If class level protection is added, please do not call it
sealed.
People from c++ might be suprised by 'private' already. We do
not have to confuse those c#ies too.
I thought the same.
Module level protection is enough to hide
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree
On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:
The point was encapsulation as you defined it was broken.
private members were directly modified outside their class. In
your words, everyone was a friend.
This is why we
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
Mmm.. that brings me back to the idea of sealed at the class
level again.
class A
{
private int x;
private(this) int y; // imagine if you have lots of private
variables.
// this could become pretty
On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:
The point was encapsulation as you defined it was broken.
private members were directly modified outside their class. In
your words, everyone was a friend.
This is why we have coding standards ;-)
On Saturday, 19 May 2018 at 09:10:32 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:
I ported your example to Java. Surprisingly, it compiled and
executed just fine:
All I see, is a class, with static members. How else would it
work?
This is the equivalent
On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:
I ported your example to Java. Surprisingly, it compiled and
executed just fine:
All I see, is a class, with static members. How else would it
work?
This is the equivalent of my D example, in Java:
( it won't even compile. phew! )
On Saturday, 19 May 2018 at 07:57:39 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
[...]
module test;
@safeinterface class Dog
{
private string noiseType = "woof";
public string makeNoise()
{
return this.noiseType;
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
So I've come full circle again, and believe my idea is worth
further consideration.
how about this (use a proper annotation).
This will be less likely to confuse anyone from other languages.
e.g
---
module test;
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree that this looks a bit strange.
My initial proposal was
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree that this looks a bit strange.
My initial proposal was
On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote:
So lets stop the pointless gentle mockery and concentrate
solely on the pointless.
Sounds like a plan!
you mean, follow your lead? now there's a plan!
I like robust conversations too ;-)
But some semblance on sanity, in that
On Friday, 18 May 2018 at 17:28:59 UTC, Steven Schveighoffer
wrote:
You can "simulate" this by putting the classes into their own
submodules of the same package.
That just another hack to get around the problem.
It's not a solution to removing the problem, from being a problem.
(yeah, I
On Friday, 18 May 2018 at 22:10:51 UTC, Maurice Huuskes wrote:
The only thing that's going to drive this discussion forward is
a few example use-cases (potentially borrowed from other
languages that ran into similar 'problems'). I am new to D
myself and how private works did surprise me but
On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote:
On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote:
On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
It
On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote:
On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
It will attract more programmers, not less - and trust me, D
On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
It will attract more programmers, not less - and trust me, D
better get more programmers using it, cause 18 years on,
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
It will attract more programmers, not less - and trust me, D
better get more programmers using it, cause 18 years on, and it
hasn't got that far, really.
"Ohh Arya you will
On Friday, 18 May 2018 at 11:41:33 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 09:07:57 UTC, Dave Jones wrote:
FFS you're so dramatic. First the world is ending because
private doesnt work as you expected. Then D is utterly useless
without the changes you want. Now we live in some
On 5/18/18 12:07 PM, Gheorghe Gabriel wrote:
Sometimes, I really need to put 2-3 or more different classes in a
module and I don't want them to share private members (friend classes).
The current solution is to create an individual module for each class,
but I don't like it when my class
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
[...]
This is simply unavoidable - and, that 'surprise' you mention,
is already there - it's not dependent on, or in any way
related, to any proposal that might result from
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:
This discussion (at least my reason for being involved in it)
is about breaking this idiotic (in my opinion) concept that D
enforces on 'everyone' - i.e the one class per module, or
everything is public, and you have no say in it.
I
On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
As clean and uncontroversial as this proposal might be, it
unfortunately doesn't resolve the biggest issue. If you try to
write Java code in D, you're still going to be using private,
and you're still going to be caught by surprise.
On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:
Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin
for multiple classes.
Example:
string var = "private(this) var;";
class A {
mixin(var);
}
class B {
mixin(var);
}
As clean
On Friday, 18 May 2018 at 12:42:05 UTC, KingJoffrey wrote:
How hard is it to convince people, that being able to have the
compiler detect semantic errors that break your defined
interface is actually a good thing. I mean really. I've had
this capability in major languages for decades.
Let
On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
You may not need a new word at all. You can also enhance
private to take arguments. Package already does this. You can
give private a symbol list that says which symbols this is
private for. So:
class A {
private int x;
private(A)
On Friday, 18 May 2018 at 12:51:42 UTC, Steven Schveighoffer
wrote:
Awesome, I love being on lists!
Well, just remember to vote *down* the dip then, cause if doesn't
get through, your quote be on my list of 'why OOP programmers
should not consider D' ;-)
It happened to me too!
On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:
private(this) int y;
This keeps the implementation simple and the scope focused.
Yeah, maybe more focused at the beginning would be better. A
comma separated list can be added later if deemed worthy.
And agreed, the java
On 5/17/18 10:08 PM, KingJoffrey wrote:
On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer wrote:
D's main draw is not OOP. So if you are here for OOP goodies, then you
are definitely better off looking elsewhere.
I'll add that too my list of D forum quotes.
Awesome, I love
On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:
Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin
for multiple classes.
Also, it also removes the redundancy of referring to the actual
class name - as in:
private(this) int i; //
On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:
private(this) int y;
I think that might be it. So clean.
This keeps the implementation simple and the scope focused. If
a DIP were put forward, I think this would be the approach to
take. Though a fairly strong case will still
On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:
Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin
for multiple classes.
Example:
string var = "private(this) var;";
class A {
mixin(var);
}
class B {
mixin(var);
}
Me like :)
On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
You may not need a new word at all. You can also enhance
private to take arguments. Package already does this. You can
give private a symbol list that says which symbols this is
private for. So:
class A {
private int x;
private(A) int
On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
I think this code has cleaner sintax:
class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
I agree. I actually
On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
[...]
I think this code has cleaner sintax:
class A {
private int x;
sealed int y;
}
void main() {
A
On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in C#
sealed as in oxford dictionary (close securely, non-porous).
On Friday, 18 May 2018 at 11:41:33 UTC, KingJoffrey wrote:
..
I should have also added:
good luck rememebering to use private, cause public is default
(ha haa haaa).
then again, private is public, so I guess it doesn't matter.
enjoy those debugging sessions...
On Friday, 18 May 2018 at 09:07:57 UTC, Dave Jones wrote:
FFS you're so dramatic. First the world is ending because
private doesnt work as you expected. Then D is utterly useless
without the changes you want. Now we live in some dystopian
nightmare where we are all slaves to the Dlang spec.
On Friday, 18 May 2018 at 02:08:47 UTC, KingJoffrey wrote:
On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer
wrote:
You're welcome to write a DIP, but I don't see a very good
chance for acceptance given the discussions on this subject.
-Steve
I agree. The D community is too
On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer
wrote:
D's main draw is not OOP. So if you are here for OOP goodies,
then you are definitely better off looking elsewhere.
I'll add that too my list of D forum quotes.
That being said, D does have OOP, and many OOP programmers
On Thursday, 17 May 2018 at 07:58:55 UTC, KingJoffrey wrote:
Remember, the idea for discussion is about adding one single
attribute 'sealed' to the class - the discussion is a lot less
about 'how can we prevent having to add a this new attribute'.
It is normal, whenever someone suggests
On 5/17/18 9:38 AM, KingJoffrey wrote:
On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer wrote:
Essentially, if you put your class you want "sealed" into it's own
module, and then publicly import the module from the API module, you
will get the same effect. This is even easier
On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer
wrote:
Essentially, if you put your class you want "sealed" into it's
own module, and then publicly import the module from the API
module, you will get the same effect. This is even easier now
with the package module than it used
On Thursday, 17 May 2018 at 11:56:51 UTC, Piotr Mitana wrote:
To sum up [TLDR]: I don't see your arguments strong enough to
alter the language (especially make a cross-language confusion
over the "sealed" keyword), but DScaner check would still allow
to track down what you consider bad.
On 5/16/18 10:32 PM, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in C#
sealed as in oxford dictionary (close securely, non-porous).
when sealed is applied
On Thursday, 17 May 2018 at 11:18:52 UTC, KingJoffrey wrote:
On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
[...]
People from c++ might be suprised by 'private' already. We do
not have to confuse those c#ies too.
On Thursday, 17 May 2018 at 11:56:51 UTC, Piotr Mitana wrote:
My opinion is that it's not worth a new keyword and time for
implementing. In the same manner you could ask for removing
friend concept from C++ as a bad concept. I don't answer the
question whether this concept is good or bad -
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in C#
sealed as in oxford dictionary (close securely, non-porous).
On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
If class level protection is added, please do not call it
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
If class level protection is added, please do not call it sealed.
People from c++ might be suprised by 'private'
On Thursday, 17 May 2018 at 07:36:40 UTC, arturg wrote:
no, that uses type inferance.
you have to do
Animal dog = new Dog;
i tried it... certainly interesting.. thanks.
but, I don't recall in my opening post, saying I'm ok with having
to create an interface for every class I create, just so
On Thursday, 17 May 2018 at 07:30:58 UTC, KingJoffrey wrote:
On Thursday, 17 May 2018 at 06:03:19 UTC, arturg wrote:
you could declare the public api of your class inside an
actual interface then use it instead of the class, that wont
give you access to the private members of the class.
On Thursday, 17 May 2018 at 06:03:19 UTC, arturg wrote:
you could declare the public api of your class inside an actual
interface then use it instead of the class, that wont give you
access to the private members of the class.
you mean like this?
module test;
On Thursday, 17 May 2018 at 05:06:54 UTC, KingJoffrey wrote:
If people want to propose putting each class in it's own
module, that does not address my requirements, and therefore is
not helpful to this discussion.
you could declare the public api of your class inside an actual
interface
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
I mean, usually we need to do a cost/benefit analysis, ...
The benefit is explained in my opening discussion.
That is, i can have more than just a single class in a module
file, as still be able to 'program to the interface' of
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
so you have more work to do if you want to convince anyone.
Again, a reminder, this is not a DIP. It's *just* a discussion.
The purpose of the discussion is not necessarly to convince
anyone, of anything.
The purpose of the
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
Can you provide even one anecdote where this would have been
useful and the workaround that has been suggested to you
multiple times (putting the type in its own module) wouldn't
have worked or would have caused other problems?
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
If you just want to vent, though, you might say that explicitly.
This is hardly a great way to start the discussion.
When I said robust, I meant useful too.
Can you provide even one anecdote where this would have been
useful and the workaround that has been suggested to you multiple
times (putting the type in its own module) wouldn't have worked
or would have caused other problems?
I mean, usually we need to do a cost/benefit analysis, and the
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
oh, and it would be great, if the D 'elite' could way in to the
discussion as well, as opposed to only waying in *after* a DIP is
put forward.
All ideas
96 matches
Mail list logo
