On Thursday, 8 November 2018 at 23:50:18 UTC, TheFireFighter
wrote:
i.e. better encapsulation really is a good thing (although for
many, it a lesson that needs to be learned).
Public/private/protected are hacks anyway - and many
object-oriented languages don't have it. They only provide
extr
On Thursday, 8 November 2018 at 23:50:18 UTC, TheFireFighter
wrote:
No it is not. You can keep saying there is, but it doesn't make
it so.
...
We don't seem to be on the same page here...do you
misunderstand what I want?
Fair enough, the exact thing you want is not possible. I
understand tha
On Thursday, 8 November 2018 at 13:18:30 UTC, Dennis wrote:
That sounds like "I just want there to be the option for
aggregate value types... without using struct.". The question
this raises is why the current solution is so problematic.
I just want (for example) to be able to write a modu
On Thursday, 8 November 2018 at 09:53:59 UTC, TheFireFighter
wrote:
well you could say the same about pointers. but..what happens
when a large number of programmers start using pointers?
I don't see the parallel between pointers and class-private.
But my argument actually is less about bugs, o
On Wednesday, 7 November 2018 at 13:15:03 UTC, Dennis wrote:
If you can't show that there are actual programmers writing
appropriately sized modules containg bugs simply because of the
lack of a class-private visibility level, then people don't
want to engineer a solution to a seemingly non-e
On Wednesday, 7 November 2018 at 13:15:03 UTC, Dennis wrote:
[snip]
"Hello, MrHaltingProblem here!
We obviously need a @noloops attribute. My co-workers are
constantly writing buggy loops with wrong loop conditions so I
NEED the extra protection. You're asking for a justification?
Trust me,
On Wednesday, 7 November 2018 at 11:00:49 UTC, TheFirefighter
wrote:
Now. How many C++/Java/C# programmers are there?
Even if a `super private` attribute or something is introduced,
the semantics of private in D will not change. Your hypothetical
C# programmer who switches to D assuming ident
On Monday, 5 November 2018 at 11:07:11 UTC, Mike Parker wrote:
So where are these teams of imperfect D programmers who are
plagued by accidental modifications of private class members?
Sociomantic? Funkwerk? Weka?
First, nobody needs to explain the problems that type errors
create.
Any de
On Monday, 5 November 2018 at 01:39:46 UTC, unprotected-entity
wrote:
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright
wrote:
On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
When one encounters a new idea that's unfamiliar sometimes
it's easy to think that because it's unfamiliar it must
On Saturday, 3 November 2018 at 04:50:52 UTC, unprotected-entity
wrote:
On Saturday, 3 November 2018 at 00:44:15 UTC, Laeeth Isharc
wrote:
[...]
I believe that responses like this, are really just designed to
further obfuscate the point I'm trying to make, so that it
cannot progress any furt
On Friday, 2 November 2018 at 10:18:11 UTC, ShadoLight wrote:
On Friday, 2 November 2018 at 00:53:52 UTC, H. S. Teoh wrote:
And along that line, recent wisdom is that it's better to move
things *out* of classes (and structs) if they don't need
access to private members. (Sorry, I wanted to in
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
On Thu, Nov 01, 2018 at 02:45:19AM +, unprotected-entity
via Digitalmars-d-announce wrote: [...]
Another thing to look for, is signs of code smell. I would
include in this, unit tests calling private methods (which
seems to be
On Wednesday, 31 October 2018 at 13:33:52 UTC, Stanislav Blinov
wrote:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole
wrote:
But at the end of the day, it just depends on the scope of the
module. Is it getting to large? If so, split.
Yup. LOC aren't a particulalry informativ
On Monday, 5 November 2018 at 11:07:11 UTC, Mike Parker wrote:
On Monday, 5 November 2018 at 09:43:06 UTC, FooledDonor wrote:
Get off your pedestal, and drop into the real life of those
who program in D with colleagues not as perfect as you are.
So where are these teams of imperfect D progr
On Monday, 5 November 2018 at 09:43:06 UTC, FooledDonor wrote:
Get off your pedestal, and drop into the real life of those who
program in D with colleagues not as perfect as you are.
So where are these teams of imperfect D programmers who are
plagued by accidental modifications of private c
On Monday, 5 November 2018 at 09:03:59 UTC, Stanislav Blinov
wrote:
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity
wrote:
On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov
wrote:
The only difference is that `func` became a member function.
And now what? You can ju
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity
wrote:
On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov
wrote:
The only difference is that `func` became a member function.
And now what? You can just as easily "forget" what's in your
struct/class as in your whole m
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity
wrote:
ok. Now, what are your options then (assuming you want an
independent type)?
(option 1) define one encapsulated type, per module.
(option 2) have a means for type independence within a module -
i.e. selective hiding.
D onl
On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov
wrote:
The only difference is that `func` became a member function.
And now what? You can just as easily "forget" what's in your
struct/class as in your whole module.
ok. Now, what are your options then (assuming you want an
ind
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote:
On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
When one encounters a new idea that's unfamiliar sometimes
it's easy to think that because it's unfamiliar it must be
unsound. That can be a mistake. It might be better to suspend
jud
On Mon, 05 Nov 2018 01:23:44 +, nobodycares wrote:
> I think there are more than enough real-world examples, of where issues
> around 'type safety', or lack of, have caused a sufficient number of
> bugs, to warrant a discussion about ways to further improve type safety.
You do realize we can a
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote:
On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
When one encounters a new idea that's unfamiliar sometimes
it's easy to think that because it's unfamiliar it must be
unsound. That can be a mistake. It might be better to suspend
jud
On Monday, 5 November 2018 at 01:23:44 UTC, nobodycares wrote:
I assume the moderator(s) doesn't like me anymore, as my posts
are no longer being published. Great way to run a discussion
forum by the way.
It not just you, my post had disappear only to reappear on later
dates. I can vouch for
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
There are many potential features that wouldn't cause problems
in isolation. Should we add all of them? Obviously not; the
result would be a horribly complex language that takes too much
time to learn and is impossible to maint
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
There are many potential features that wouldn't cause problems
in isolation. Should we add all of them? Obviously not; the
result would be a horribly complex language that takes too much
time to learn and is impossible to maint
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
On Sun, 04 Nov 2018 11:36:39 +, FooledDonor wrote:
Can we argue about the problems arising from the potential
introduction of this feature?
There are many potential features that wouldn't cause problems
in isolation. Should
On Saturday, 3 November 2018 at 03:58:16 UTC, Ali Çehreli wrote:
On 11/02/2018 03:18 AM, ShadoLight wrote:
> Maybe you are thinking of the "Prefer non-member non-friend
functions to
> member functions" rule from Herb Sutter's "Effective C++"
books?
Scott Meyers.
Ali
Thanks for the correctio
On Sun, 04 Nov 2018 11:36:39 +, FooledDonor wrote:
> Can we argue about the problems arising from the potential introduction
> of this feature?
There are many potential features that wouldn't cause problems in
isolation. Should we add all of them? Obviously not; the result would be a
horribl
On Saturday, 3 November 2018 at 16:21:36 UTC, Neia Neutuladh
wrote:
On Sat, 03 Nov 2018 11:24:06 +, FooledDonor wrote:
And if the validity of a person's reasoning is a function of
his way of expressing them, well ... do not pose to software
engineers at least
If you want other people to d
On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
When one encounters a new idea that's unfamiliar sometimes it's easy to think
that because it's unfamiliar it must be unsound. That can be a mistake. It
might be better to suspend judgement for a while and keep an open mind.
So true. My ideas on how
On Saturday, 3 November 2018 at 20:38:29 UTC, unprotected-entity
wrote:
As has been pointed out several times before, this is a contrived
example. Allow a simple transformation:
```
module test;
struct S
{
private uint a;
void setA(uint n)
{
// damn implicit conversions!
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh
wrote:
We object because the people complaining can't point at a use
case that seems reasonable. If you provided real-world
examples, we'd consider them.
--
module test;
struct S
{
private uint a;
void setA(uint n)
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh
wrote:
On Sat, 03 Nov 2018 04:50:52 +, unprotected-entity wrote:
(q1) Why is it, that people who use D, object *so much* to the
idea of
allowing (at the choice of the programmer) for a type to have
it's own
private state *within*
On Sat, 03 Nov 2018 11:24:06 +, FooledDonor wrote:
> And if the validity of a person's reasoning is a function of his way of
> expressing them, well ... do not pose to software engineers at least
If you want other people to do work for you, you need to convince them to
do it. This is an open
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh
wrote:
On Sat, 03 Nov 2018 04:50:52 +, unprotected-entity wrote:
(q1) Why is it, that people who use D, object *so much* to the
idea of
allowing (at the choice of the programmer) for a type to have
it's own
private state *within*
On Sat, 03 Nov 2018 04:50:52 +, unprotected-entity wrote:
> (q1) Why is it, that people who use D, object *so much* to the idea of
> allowing (at the choice of the programmer) for a type to have it's own
> private state *within* a module (so that its private state is respected
> by other code a
On Saturday, 3 November 2018 at 00:44:15 UTC, Laeeth Isharc wrote:
When one encounters a new idea that's unfamiliar sometimes it's
easy to think that because it's unfamiliar it must be unsound.
That can be a mistake. It might be better to suspend judgement
for a while and keep an open mind.
On 11/02/2018 03:18 AM, ShadoLight wrote:
> Maybe you are thinking of the "Prefer non-member non-friend functions to
> member functions" rule from Herb Sutter's "Effective C++" books?
Scott Meyers.
Ali
On Thursday, 1 November 2018 at 22:37:59 UTC, unprotected-entity
wrote:
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
Actually, code within a module *should* be tightly coupled and
cohesive -- that's the whole reason to put that code inside a
single module in the first place
On Friday, 2 November 2018 at 05:29:39 UTC, Neia Neutuladh wrote:
It's also not obviously so useful as to merit inclusion.
No. I don't say it merits inclusion.
I do say it merits discussion, as to its merits.
But from what I see, so far, is D, Go, Rust...they are seem to
have a love affair w
On Fri, Nov 02, 2018 at 10:18:11AM +, ShadoLight via Digitalmars-d-announce
wrote:
> On Friday, 2 November 2018 at 00:53:52 UTC, H. S. Teoh wrote:
> >
> > And along that line, recent wisdom is that it's better to move
> > things *out* of classes (and structs) if they don't need access to
> >
On Friday, 2 November 2018 at 00:53:52 UTC, H. S. Teoh wrote:
And along that line, recent wisdom is that it's better to move
things *out* of classes (and structs) if they don't need access
to private members. (Sorry, I wanted to include a link for
this, but I couldn't find the article -- the
On Thu, 01 Nov 2018 22:37:59 +, unprotected-entity wrote:
> On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
>>
>> Actually, code within a module *should* be tightly coupled and cohesive
>> -- that's the whole reason to put that code inside a single module in
>> the first place.
On Thursday, 1 November 2018 at 23:58:15 UTC, H. S. Teoh wrote:
Having said that, though, there are some here who *do* want
something like what you describe... IIRC Manu has voiced this
before, and there may be others. (I myself don't consider it a
big enough issue to be worth agonizing over.
On Fri, Nov 02, 2018 at 12:25:21AM +, unprotected-entity via
Digitalmars-d-announce wrote:
[...]
> "Encapsulation is sometimes referred to as the first pillar or
> principle of object-oriented programming. According to the principle
> of encapsulation, a class or struct can specify how accessi
On Wednesday, 31 October 2018 at 10:48:24 UTC, Sebastien Alaiwan
wrote:
"Encapsulation" is about implementation hiding and access
control ("public/private"), and requires programming language
support (e.g most dynamic languages don't have it).
"Encapsulation is sometimes referred to as the f
On Thu, Nov 01, 2018 at 10:37:59PM +, unprotected-entity via
Digitalmars-d-announce wrote:
> On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
> >
> > Actually, code within a module *should* be tightly coupled and
> > cohesive -- that's the whole reason to put that code inside a
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
Actually, code within a module *should* be tightly coupled and
cohesive -- that's the whole reason to put that code inside a
single module in the first place. If two pieces of code inside
a module are only weakly coupled or comp
On Thu, Nov 01, 2018 at 02:45:19AM +, unprotected-entity via
Digitalmars-d-announce wrote:
[...]
> Another thing to look for, is signs of code smell. I would include in
> this, unit tests calling private methods (which seems to be a popular
> thing for D programmers to do). Some will disagree
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole
wrote:
On 01/11/2018 2:25 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki
cattermole wrote:
On 01/11/2018 2:16 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas
Wilson wrote
On Wednesday, 31 October 2018 at 20:23:21 UTC, Walter Bright
wrote:
On 10/31/2018 6:25 AM, 12345swordy wrote:
Again what consist of a module of being "too large"?
That seems to me that more of a art then a science.
If you're looking for a rigid rule, you won't find one.
But a good indicator i
On Wednesday, 31 October 2018 at 20:24:36 UTC, 12345swordy wrote:
This is an counter argument how?
It isn't a counter argument (at least not to you).
Just saying that I wrote a 14,000 line module, and maintain a
contributed 15,000 line one. It works for me! lol
On 10/31/2018 6:25 AM, 12345swordy wrote:
Again what consist of a module of being "too large"?
That seems to me that more of a art then a science.
If you're looking for a rigid rule, you won't find one.
But a good indicator is if it contains more than one abstraction that has
nothing particul
On Wednesday, 31 October 2018 at 13:24:10 UTC, Adam D. Ruppe
wrote:
On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy
wrote:
I seen modules with more then thousand lines of code in the
Phobos library.
$ wc simpledisplay.d nanovega.d dom.d cgi.d
14152 54984 443111 simpledisplay.d
On Wednesday, 31 October 2018 at 13:39:25 UTC, rikki cattermole
wrote:
On 01/11/2018 2:35 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki
cattermole wrote:
On 01/11/2018 2:25 AM, 12345swordy wrote:
[...]
Because it is.
My rules (which tend to be a little stricter
On 10/31/2018 3:48 AM, Sebastien Alaiwan wrote:
I think there might be some confusion between "leaky abstraction" and
"insufficient encapsulation".
Thanks for the excellent description of the difference.
On 01/11/2018 2:42 AM, Stanislav Blinov wrote:
Well, yes, it can be a litmus test, I guess. I meant to say that it
isn't per se a deciding factor.
It is a deciding factor for me. Because it seems to be almost always
correct. As I said, my rules are stricter than what most people have.
My pre
On Wednesday, 31 October 2018 at 13:37:07 UTC, rikki cattermole
wrote:
On 01/11/2018 2:33 AM, Stanislav Blinov wrote:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki
cattermole wrote:
But at the end of the day, it just depends on the scope of
the module. Is it getting to large? If so, sp
On 01/11/2018 2:35 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
On 01/11/2018 2:25 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote:
On 01/11/2018 2:16 AM, 12345swordy wrote:
[...]
We have been spli
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole
wrote:
On 01/11/2018 2:25 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki
cattermole wrote:
On 01/11/2018 2:16 AM, 12345swordy wrote:
[...]
We have been splitting Phobos modules up:
std.algorithm and
On 01/11/2018 2:33 AM, Stanislav Blinov wrote:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
But at the end of the day, it just depends on the scope of the module.
Is it getting to large? If so, split.
Yup. LOC aren't a particulalry informative metric. Documentation,
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole
wrote:
But at the end of the day, it just depends on the scope of the
module. Is it getting to large? If so, split.
Yup. LOC aren't a particulalry informative metric. Documentation,
comments, unit tests, blanks, all contribute t
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole
wrote:
On 01/11/2018 2:16 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson
wrote:
Running into such problems is a sign that your module is too
large, and should become a package.
I seen modules
On 01/11/2018 2:25 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote:
On 01/11/2018 2:16 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote:
Running into such problems is a sign that your module is too large,
a
On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy wrote:
I seen modules with more then thousand lines of code in the
Phobos library.
$ wc simpledisplay.d nanovega.d dom.d cgi.d
14152 54984 443111 simpledisplay.d
15289 63707 573986 nanovega.d
7159 24473 187572 dom.d
4
On 01/11/2018 2:16 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote:
Running into such problems is a sign that your module is too large,
and should become a package.
I seen modules with more then thousand lines of code in the Phobos
library. What exact
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson
wrote:
Running into such problems is a sign that your module is too
large, and should become a package.
I seen modules with more then thousand lines of code in the
Phobos library. What exactly consist a module of being "too
large"?
On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell
wrote:
in D, once your write your abstraction, say a class, with it's
public interface, all the code below it can do whatever it
likes to that class, making it a leaky abstraction.
I think there might be some confusion between "lea
On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell
wrote:
I did find it confusing however, that you discuss leaky
abstractions, and putting your public interface at the
beginning of your code (and all the other crap below it)... but
then, in D, once your write your abstraction, say
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
Had a nice crowd there last night. Apparently lots of people
were interested in this topic!
Video:
https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be
Interesting talk. Thanks for the link.
I did find it confusing
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
On 10/15/2018 2:23 PM, Walter Bright wrote:
I'm giving a presentation at:
http://nwcpp.org/
See you there!
Had a nice crowd there last night. Apparently lots of people
were interested in this topic!
Video:
https://www.youtu
On 10/21/2018 1:29 PM, David Gileadi wrote:
There’s a bit more to the story, but it boils down to the fact that since I
don’t have permissions to update the feature branch, I’m basically dead in
the water. So the work is all done and ready, but I have no path forward to
get it in. And it’s a bit
luckoverthere wrote:
> On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
>> On 10/15/2018 2:23 PM, Walter Bright wrote:
>>> I'm giving a presentation at:
>>>
>>> http://nwcpp.org/
>>>
>>> See you there!
>>
>> Had a nice crowd there last night. Apparently lots of people
>> were i
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
On 10/15/2018 2:23 PM, Walter Bright wrote:
I'm giving a presentation at:
http://nwcpp.org/
See you there!
Had a nice crowd there last night. Apparently lots of people
were interested in this topic!
Video:
https://www.youtu
On 10/15/2018 2:23 PM, Walter Bright wrote:
I'm giving a presentation at:
http://nwcpp.org/
See you there!
Had a nice crowd there last night. Apparently lots of people were interested in
this topic!
Video: https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be
Slides: http://nwcpp.o
75 matches
Mail list logo
