Re: Module-level privacy
On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote: Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D. Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations. First, this thread was about extending the capabilities of classes in D with some new attribute/capability - sealed. I thought it was first important to point out, in this thread, as opposed to a separate thread, that classes in D are already problematic, because modules do not respect the encapsulation boundaries of classes, and any discussion about further extending classes should be approached with great caution - because the problem will only become even more entrenched. Second, writing a DIP is pointless, since Walter likes the idea that the module doesn't protect the encapsulation boundary of the class. Now if Walter thinks that's fine, what is a DIP going to do? I mean really. I have better things to do. Third, those who responded to my caution are the ones that should have created a separate thread, not me. Finally (and I do mean finally), my concern about the loss of the encapsulation boundary of classes in D, has a very real impact on the quality and maintainability of software systems developed in D. That the designer of D apparently thinks otherwise, baffles me.
Re: errno is not nothrow
On Friday, 11 May 2018 at 19:01:05 UTC, H. S. Teoh wrote:
This sounds scary. So my (strongly!) pure function that
returns floating-point can return different results when passed
the same parameters, if somebody in between changes
floating-point flags? That doesn't sound good at all.
This is an ugly problem, and I'm not sure what the best solution
would be. The current one is simple to understand and only has a
little surprising behavior (multiple invocations to the same pure
function with the same parameters might yield the same results,
even if floating point flags have changed).
I'd like to hear about any reasonable alternatives. Here are a
few unreasonable ones I thought up:
1. The compiler could have the function store its FPU flag state
somewhere. It would involve adding a preamble to each pure
function:
---
static bool fpeInitialized = false;
static fenv_t fpeEnv;
fenv_t previous;
if (fegetenv(&previous)) assert(0, "failed to get FPU
environment");
scope (exit) if (fesetenv(&previous)) assert(0, "failed to
restore FPU environment");
if (fpeInitialized)
{
fesetenv(&fpeEnv);
}
else
{
fpeEnv = previous;
fpeInitialized = true;
}
---
On my machine, that's an overhead of about 2.5 microseconds per
function call. On top of a trivial pure function, it's a 47×
overhead.
But ignoring the performance cost, is that even vaguely
desirable? Whatever you first call the pure function with, it's
always going to use the same FPU environment. Accidentally call
it inside a static constructor and you set your FPU flags in
main() ? Your intent is silently ignored. And should the FPU
environment be thread-local? If it isn't, I might see different
results if I run the same code in different threads. If it is,
then the compiler might need to use atomic variables or locking,
and that would be horribly slow. Plus a surprising runtime
dependency, probably, that prevents pure functions from working
with -betterC.
2. Pure functions could require you to inform the compiler of
your desired FPU flags. This means the compiler, not the runtime,
needs to know about how to set FPU flags on every supported
architecture. It also means it's a lot harder to use pure
functions, and they're less portable. They will also all have
overhead from setting FPU flags and resetting them after, but it
fixes all the other problems from the first option.
3. You could tell the compiler to watch out for people changing
the FPU environment, and then it won't try to omit duplicate
function calls. This means any function that the compiler is not
going to emit into the same object file, or that might be
overridden in another object file. It eats into the promise that
adding `pure` means your code becomes faster automatically.
Re: Module-level privacy
On 13/05/2018 5:11 PM, Neia Neutuladh wrote: On Sunday, 13 May 2018 at 02:36:28 UTC, KingJoffrey wrote: On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote: And please, if this bothers you so much, start a new thread. You're spamming someone else's feature request by going off topic. yeah, I know how much *you* (and many others) would like to shutdown any discussion about the absurd way in which classes are treated in D. It's a touchy topic it seems. Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D. I have a draft DIP hanging around on my hard drive relating to named function parameters, for instance. It discusses: * The thing to be changed * Why I think it should be changed * Examples of how the status quo causes problems * How I want code to work in the future * Examples of what I want code to look like * How other languages handle this thing That's just due diligence for nontrivial enhancement requests. And named function parameters is a feature with probably very little opposition and moderate support. so take your own advice. create a new thread, and have a go at me there instead. It should be as easy as changing the "Subject" field on the reply screen. It would have been gracious of you to do this, all things considered. When someone creates a topic about extending the capacity of classes in D, I will always feel the urge to remind them, that classes in D are a complete joke - and that you shouldn't bother using them. Better to use another language that has the capacity to respect the encapsulation barrier of the class. Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations. On that note we should chat[0]. Preferably IRC or Discord. [0] https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md
Re: Module-level privacy
On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote: It should be as easy as changing the "Subject" field on the reply screen. Apparently not. My apologies.
Module-level privacy
On Sunday, 13 May 2018 at 02:36:28 UTC, KingJoffrey wrote: On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote: And please, if this bothers you so much, start a new thread. You're spamming someone else's feature request by going off topic. yeah, I know how much *you* (and many others) would like to shutdown any discussion about the absurd way in which classes are treated in D. It's a touchy topic it seems. Nobody's getting worked up about this, and nobody's telling you to stop talking about it. There have been suggestions that you write up a DIP for it. This is a standard process for suggesting improvements to D. I have a draft DIP hanging around on my hard drive relating to named function parameters, for instance. It discusses: * The thing to be changed * Why I think it should be changed * Examples of how the status quo causes problems * How I want code to work in the future * Examples of what I want code to look like * How other languages handle this thing That's just due diligence for nontrivial enhancement requests. And named function parameters is a feature with probably very little opposition and moderate support. so take your own advice. create a new thread, and have a go at me there instead. It should be as easy as changing the "Subject" field on the reply screen. It would have been gracious of you to do this, all things considered. When someone creates a topic about extending the capacity of classes in D, I will always feel the urge to remind them, that classes in D are a complete joke - and that you shouldn't bother using them. Better to use another language that has the capacity to respect the encapsulation barrier of the class. Your complaint is about protection, not about classes. It should affect all definitions. Perhaps you simply don't expect type-level encapsulation for structs and top-level declarations.
Re: auto: useful, annoying or bad practice?
On Friday, 11 May 2018 at 18:44:25 UTC, H. S. Teoh wrote:
On Fri, May 11, 2018 at 04:57:05PM +, Mark via
Digitalmars-d wrote:
On Wednesday, 9 May 2018 at 15:06:55 UTC, Jonathan M Davis
wrote:
> Ultimately, the key is that the user of the function needs
> to be able to know how to use the return type. In some
> cases, that means returning a specific type, whereas in
> others, it means using auto and being clear in the
> documentation about what kind of API the return type has. As
> long as the API is clear, then auto can be fantastic, but if
> the documentation is poorly written (or non-existant), then
> it can be a serious problem.
>
> - Jonathan M Davis
He also needs to know what requirements the parameters of the
function should satisfy. We have template constraints for
that, even though that could also have been "implemented"
through documentation.
This makes me wonder if it might be useful to have return-type
constraints. A kind of static out-contract? Something that's
part of the function declaration, that ensures that the return
type satisfies certain properties.
// Hypothetical syntax
auto myfunc(R)(R r)
if (isInputRange!R &&
isOutputRange!return)
{
... // implementation here
}
The `isOutputRange!return` (this is just tentative syntax, you
guys can probably think of better ways of writing this)
statically enforces that the return type must satisfy
`isOutputRange`, and, being part of the function signature,
documents to the user what to expect of it.
-
T
This method won't work for non-template functions (since template
constraints can be used only in, well, templates). Granted,
non-template functions with auto return type are pretty rare, but
we probably don't want to impose an unnecessary restriction.
Re: Sealed classes - would you want them in D?
On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote: Again, all you have to do is put class Person in a separate module. This is such a nonsense solution. Why do you keep proposing it? Is this you way to effectively sweep the problem under the carpet? For me, a module presents the opportunity to group objects into a larger working unit. But since D does not respect the encapsulation of objects, one has to revert to your solution, or mine (which is, if you're solution to a problem requires the use of classes, then go use a progamming language that respects the encapsulation boundary of classes).
Re: Sealed classes - would you want them in D?
On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote: And please, if this bothers you so much, start a new thread. You're spamming someone else's feature request by going off topic. yeah, I know how much *you* (and many others) would like to shutdown any discussion about the absurd way in which classes are treated in D. It's a touchy topic it seems. Now, if I were having this discussion with myself, your comment about spamming the topic 'might' be correct. As it is though, everyone involved in the discussion, including yourself, is spamming the topic, in that case. so take your own advice. create a new thread, and have a go at me there instead. When someone creates a topic about extending the capacity of classes in D, I will always feel the urge to remind them, that classes in D are a complete joke - and that you shouldn't bother using them. Better to use another language that has the capacity to respect the encapsulation barrier of the class.
Re: Sealed classes - would you want them in D?
On Sunday, 13 May 2018 at 01:52:20 UTC, KingJoffrey wrote:
On Saturday, 12 May 2018 at 18:36:59 UTC, Walter Bright wrote:
On 5/12/2018 9:42 AM, Mike Parker wrote:
Thank goodness we don't have to do this silliness.
[...]
module test;
import std.stdio : writeln;
void main()
{
Person p = new Person("King Joffrey");
writeln(p.getName); // I designed my class to present this
interface.
writeln(p._name); // The module couldn't care less about
your interface.
p._name = "King Walter"; // even worse, the module can
de-throne the king!!
writeln(p._name);
}
class Person
{
private string _name;
public void setName(string name)
{
this._name = name;
}
public string getName()
{
return ProperName(this._name);
}
public this(string name)
{
_name = name;
}
private static string ProperName(string name)
{
return name ~ " : The one true king!";
}
}
===
Again, all you have to do is put class Person in a separate
module. Its not that hard. Why is main in the same module if it
isn't logically related to Person? It should be in its own
module. Its uses Person. main does not extend person, it needs
only the public bits. So it goes in its own module. And please,
if this bothers you so much, start a new thread. You're spamming
someone else's feature request by going off topic.
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 18:19:48 UTC, Jonathan M Davis wrote: I have never seen encapsulation issues where someone accidentally uses some private piece of a class or struct by accident elsewhere in the module, and the code therefore ends up with a bug. Then you've never seem me program. That bug you mention, is something that has often popped up in my program, because the compiler didn't warn me - hey, that stuff is private, shouldn't you be using the getter, or setter. This loss of encapsulation, is why I no longer use classes in D.
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 18:36:59 UTC, Walter Bright wrote:
On 5/12/2018 9:42 AM, Mike Parker wrote:
Thank goodness we don't have to do this silliness.
I always thought the 'friend' business in C++ was an awful
hack. But C++ didn't have modules, and modules are a much
better solution to that problem.
Modules would only be a better solution, if, and only if, the
programmer still had control over class level encapsulation.
At least 'friend' in c++, is in the control of the programmer.
D has decided the programmer doesn't need this control anymore,
takes that control away, and gives it to the module - the
programmer has no say in it - even if the programmer want's it
private, the module overrides private!!
I would expect, that like me, 10's of millions of other
programmers would not be comfortable with this.
That the '< 1000' D programmers think otherwise, doesn't make the
case.
Go back and give the programmer control, as to whether the class
or the module has the greater authority, and perhaps...then... D
will attract more programmers.
Feel free to show the code below, to all the C#/C++/Java
programmers out there - I'm sure they'll love what D has done
with the class-module interaction.
module test;
import std.stdio : writeln;
void main()
{
Person p = new Person("King Joffrey");
writeln(p.getName); // I designed my class to present this
interface.
writeln(p._name); // The module couldn't care less about your
interface.
p._name = "King Walter"; // even worse, the module can
de-throne the king!!
writeln(p._name);
}
class Person
{
private string _name;
public void setName(string name)
{
this._name = name;
}
public string getName()
{
return ProperName(this._name);
}
public this(string name)
{
_name = name;
}
private static string ProperName(string name)
{
return name ~ " : The one true king!";
}
}
===
Re: Two really good looking GUI libraries that can work for D
On Saturday, 12 May 2018 at 19:03:50 UTC, aberba wrote: On Friday, 11 May 2018 at 23:13:06 UTC, Rubn wrote: On Friday, 11 May 2018 at 21:43:24 UTC, aberba wrote: [...] If you are going to mention that then you might as well mention the (imo better) alternative ImGui. https://github.com/ocornut/imgui https://github.com/Extrawurst/cimgui Compare imgui with Nuklear (https://github.com/vurtun/nuklear) and see the difference in the features and polish. Yes ImGui is more polished and is incredibly easy to extend, creating UI you'll only use once takes no time at all and helps incredibly with debugging those annoying bugs. Blizzard's also contributed to the project so the author is able to dedicate even more time to the project. https://github.com/ocornut/imgui/issues/1607
Re: Two really good looking GUI libraries that can work for D
On 05/11/2018 05:43 PM, aberba wrote: > > https://littlevgl.com/ > On 05/12/2018 03:03 PM, aberba wrote: On Friday, 11 May 2018 at 23:13:06 UTC, Rubn wrote: https://github.com/ocornut/imgui https://github.com/Extrawurst/cimgui Compare imgui with Nuklear (https://github.com/vurtun/nuklear) and see the difference in the features and polish. Y'know, even though I'm normally very "native UI or bust!" (outside of videogames anyway), I have to say, for non-native, LittlevGL and Nuklear are *REALLY* nice looking. It's also very, very cool that they seem to be designed with embedded in mind. Also very cool that imgui appears to have been used for that cool Wonder Boy 3 remake. I'll definitely have to remember these if I need to do an embedded or in-game-engine UI.
Re: Two really good looking GUI libraries that can work for D
On Friday, 11 May 2018 at 21:43:24 UTC, aberba wrote: This two GUI libs written in C I just found are really good looking and looks production ready. Embedded systems: LittlevGL is a free and open-source graphics library providing everything you need to create embedded GUI with easy-to-use graphical elements, beautiful visual effects and low memory footprint. Powerful building blocks: buttons, charts, lists, sliders, images etc Advanced graphics with animations, anti-aliasing, opacity, smooth scrolling Various input devices: touch pad, mouse, keyboard, encoder etc Multi language support with UTF-8 decoding Fully customizable graphical elements https://littlevgl.com/ I didn't know this one and it looks nice, maybe not too adapted to big desktop apps. Based on the screenshots this looks more designed for skeuomorphic UIs or small UIs, e.g mobile dev.
Re: Two really good looking GUI libraries that can work for D
On Friday, 11 May 2018 at 23:13:06 UTC, Rubn wrote: On Friday, 11 May 2018 at 21:43:24 UTC, aberba wrote: [...] If you are going to mention that then you might as well mention the (imo better) alternative ImGui. https://github.com/ocornut/imgui https://github.com/Extrawurst/cimgui Compare imgui with Nuklear (https://github.com/vurtun/nuklear) and see the difference in the features and polish.
Re: Sealed classes - would you want them in D?
On 5/12/2018 9:42 AM, Mike Parker wrote: Thank goodness we don't have to do this silliness. I always thought the 'friend' business in C++ was an awful hack. But C++ didn't have modules, and modules are a much better solution to that problem.
Re: Sealed classes - would you want them in D?
On Saturday, May 12, 2018 08:13:12 KingJoffrey via Digitalmars-d wrote: > On Saturday, 12 May 2018 at 07:39:04 UTC, Jonathan M Davis wrote: > > Ultimately, it's a tradeoff, and arguments can be made for and > > against. But in practice, it works extremely well. You're > > certainly free to not like this particular design choice, but > > it's one that most of us have no problem with, and I'd be > > shocked to ever see it change. So, you can be unhappy about it, > > but complaining isn't going to change anything. You're either > > going to have to just learn to live with it or not use D. > > > > - Jonathan M Davis > > I'm not so much complaining about it, as warning others of it. > > D modules do NOT (cannot) respect the encapsulation of the class, > and therefore, D modules containing classes, can very easily (to > borrow a phrase from Bertrand Meyer) start to resemble "a chunk > of Swiss cheese that has been left outside for too long..". > > As for using D, this is why I don't really use D for anything > other than small tasks - where I can happily revert to procedural > type programming ( C like), and not have to worry about the > issues of broken class encapsulation - which will almost > certainly lead to unexpected side-effects, and create whole new > 'class' of problems that D programmers have to deal with. Honestly, the only time that I've ever seen problems related to the fact that private relates to the module and not the struct or class is when there's a problem with a unit tests due to the fact that it's not restricted in the same way that user code would be e.g. - if a symbol is accidentally private, the unit test won't catch that. I have never seen encapsulation issues where someone accidentally uses some private piece of a class or struct by accident elsewhere in the module, and the code therefore ends up with a bug. I'm not about to claim that it's impossible to make such a mistake, but I've never seen one, and in my experience, the fact that everything in a module can access everything else in a module (except that functions can't reach into each other) is a complete non-issue and if anything makes life simpler, because it completely negates the need to worry about friends in those cases where you really do need to reach into the innards of a class or struct within the module. To many of use, you're making a mountain out a mole hill here. While I can understand why what D has done with private might be disturbing to someone when they first come to D, in practice, it's proven to work quite well without causing unexpected side-effects and stray bugs. Maybe it would be worse if D didn't encourage unit testing the way that it does (I don't know), but I can unequivocably say that what D has done with private has worked wonderfully for me and most of the programmers who use D. - Jonathan M Davis
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 15:48:53 UTC, KingJoffrey wrote:
Actually, that is not true. If it were true, then I could do:
module test;
void main() { i = 2; } // sorry, but i belongs to another unit
of encapsulation
void foo() { int i = 1; }
D only breaks the encapsulation properties of classes, not
functions.
But that's why we have functions and classes - which are their
own level of smaller units of encapsulation. Blurring the
boundary of encapsulation seems like a big step backward in
terms of structured programming.
Each unit of code (a function, a class, a module) should
respect the encapsulation properties of each other.
Encapsulation and scope are not the same thing.
There's simply no point in using classes in D, as they have no
capacity to encapsulate themselves
Yes, they do. The private API is not visible to the outside world.
Now if 'private' meant 'private to the class' (as most people
would rightly expect), and the default if you had no attribute
was, say, 'accessible to the module', then I could probably
live with that, and I would start to use classes in D
productively.
I'm using classes productively right now. Having private class
members accessible in the module is a boon, not a hindrance, IMO.
But when the class has lost its capacity to encapsulate, it's
lost its purpose.
It hasn't lost its ability to encapsulate. The private
implementation is hidden from the outside world and does not
impact the public API.
Making us hold whole modules in memory so we can reason about
the interaction between classes and modules, is just nonsense,
in my opinion.
No, nonsense would look like this:
```
module mymmod;
class Foo {
private int _x;
/* module private */ int x() { return _x; }
}
class Bar {
private int _y;
/* module private */ int y() { return _y; }
}
void printFooBar(Foo f, Bar b) {
import std.stdio : writefln;
writefln("f.x = %s, b.y = %s", f.x, b.y);
}
```
Thank goodness we don't have to do this silliness.
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 13:38:18 UTC, Walter Bright wrote:
Mike's right. D's encapsulation model is designed around the
module.
Actually, that is not true. If it were true, then I could do:
module test;
void main() { i = 2; } // sorry, but i belongs to another unit
of encapsulation
void foo() { int i = 1; }
D only breaks the encapsulation properties of classes, not
functions.
Since the vast majority of programmers use classes as the basis
for encapsulation, this surely presents a significant problem to
those coming over to D, rightly expecting that encapsulation to
be retained.
If a module is too large to be comprehended, it should be
broken up into smaller modules, each with its encapsulated
functionality.
But that's why we have functions and classes - which are their
own level of smaller units of encapsulation. Blurring the
boundary of encapsulation seems like a big step backward in terms
of structured programming.
Each unit of code (a function, a class, a module) should respect
the encapsulation properties of each other.
There's simply no point in using classes in D, as they have no
capacity to encapsulate themselves (whereas function still retain
this privilege)
Now if 'private' meant 'private to the class' (as most people
would rightly expect), and the default if you had no attribute
was, say, 'accessible to the module', then I could probably live
with that, and I would start to use classes in D productively.
But when the class has lost its capacity to encapsulate, it's
lost its purpose.
It is hard enough to hold a class in working memory so you can
reason about.
Making us hold whole modules in memory so we can reason about the
interaction between classes and modules, is just nonsense, in my
opinion.
Re: Sealed classes - would you want them in D?
On 5/12/2018 8:18 AM, Piotr Mitana wrote:
What I am trying to do is:
== a.d
class P
{
private this();
}
final class C1 : P { }
final class C2 : P { }
test.d
import a;
void foo()
{
P[] twoPs = [ new C1(), new C2() ]; // works
}
class C3 : P // fails
{
}
dmd test a
Error: constructor a.P.this is not accessible from module test
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 10:27:11 UTC, Walter Bright wrote:
The solution is:
private class MyClass { ... }
public final MyClassSealed : MyClass { }
Meaning other modules can use MyClassSealed but cannot derive
from it. Other classes inside the module can derive from
MyClass as required.
It is not. Other modules can use MyClassSealed - yes. Inheritance
is possible only im module - yes. But these are two different
classes still. If we have two of extending classes:
private class Parent {}
public final class Child1 : Parent {}
public final class Child2 : Parent {}
Then it is true that I can inherit Parent outside the module, but
I can't use it as well. In this case I can't create an array
(other then Object[]) that can hold both Child1 and Child2
outside the module.
What I want is to see the supertype *everywhere* and be able to
use it for example to create an array of Parents, but not be able
to create Child3 : Parent elsewhere then in the module where
Parent resides.
public final class ParentSealed : Parent {}
won't help - it will be just the same as two ChildX classes and
still won't have a *visible* supertype other then Object with
them.
What I am trying to do is:
/* foo.d */
module foo;
sealed class Parent {}
final class Child1 : Parent {}
final class Child2 : Parent {}
/* bar.d */
module bar;
import foo;
static this
{
Parent[] twoParents = [new Child1(), new Child2()]; //
Parent is still visible
}
class Child3 : Parent {} // ERROR: Parent is sealed and cannot
be extended outside module foo
I don't think that it is possible to rewrite this code without
sealed, but still having Child3 illegal and the Parent[] array
creatable in the module bar.
Another example - taken directly from Scala. In Scala optionals
are defined via a set of classes ("[T]" is Scala's version for
Java's ""):
sealed abstract class Option[T] {}
final case class Some[T] extends Option[T] {}
object None extends Option[Nothing] {}
For the sake of simplicity let's don't dive in how "case class"
and "object" are different from typical classes. Also let's
assume that Nothing extends T (in fact Scala's Nothing extends
every possible type)
You can declare an Option[Int] variable everywhere and assign
Some(value) or None to it. All three classes are visible from
everywhere, but as Option is sealed, you can't create
class OnlyOnMonday[T] extends Option[T] {}
in the other module (effectively nowhere, as Option is a part of
the standard library).
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 06:42:24 UTC, rumbu wrote: Testing private functionality means that you *lock* the internal implementation of your class. If you decide later to change the implementation, your previous tests will have zero-value. I did TDD at a company for three years. Tests didn't survive refactoring. These days, I have tests to ensure correctness, and they can tell me when public interfaces change. I usually don't need tests to tell me that, but they help just in case. I also tend to have examples projects for anything more complex, which reduces the amount of trouble I can get myself into. Plus the majority of my code is in applications rather than libraries, so consistent interfaces aren't nearly as important (as long as static typing catches the majority of incorrect calls and contracts catch the rest).
Re: Sealed classes - would you want them in D?
On 5/11/2018 8:02 PM, KingJoffrey wrote: On Saturday, 12 May 2018 at 00:39:29 UTC, Mike Parker wrote: Again, they're in the same module. From an encapsulation stand point, what does it matter that private members are within or without any specific set of curly braces? It only matters if you want to adhere to a purely conceptual view of encapsulation. From a practical view, it matters not one whit. It matters, in the same sense, that it matters if you have a module, full of functions (which are encapsulated units of code), but your module has a whole bunch of goto statements (not necessarily within a function). Now...you've essentially no idea now which functions are truly encapsulated, and which aren't. Mike's right. D's encapsulation model is designed around the module. If a module is too large to be comprehended, it should be broken up into smaller modules, each with its encapsulated functionality.
Re: [DUB][DLS] building package dls doesn't finish
On Saturday, 12 May 2018 at 11:32:29 UTC, Kamil Koczurek wrote: That's great! If I may ask, releasing a new version is a matter of hours or days? 'Very soon' is rather vague. Well... that's pretty much why I say 'very soon' in fact; I intended to release a new version around one or two weeks ago already, but I found problem after problem in my code. I would say that at worst, by tomorow evening there should be a new release.
Re: [DUB][DLS] building package dls doesn't finish
On Saturday, 12 May 2018 at 11:26:22 UTC, Laurent Tréguier wrote: On Thursday, 10 May 2018 at 09:32:38 UTC, Kamil Koczurek wrote: [...] Hello there, I'm developing DLS, and there is indeed a big problem with dependency resolution. It's fixed currently in the dls master branch, and I need to fix a few other things, but a new release should be coming very soon. It's still going to take time to build, but the next version should build properly. That's great! If I may ask, releasing a new version is a matter of hours or days? 'Very soon' is rather vague.
Re: [DUB][DLS] building package dls doesn't finish
On Thursday, 10 May 2018 at 09:32:38 UTC, Kamil Koczurek wrote: Hello, I installed an atom extension for D support, but it requires dls package to be installed and built. When I fetch and attempt to build it (with --build=release) it just says that it's building and doesn't change even if I leave it running for several hours. What can I do to fix it? Or do I just leave it overnight? Ps. Sorry if it's a wrong section, it's my first time posting here. Hello there, I'm developing DLS, and there is indeed a big problem with dependency resolution. It's fixed currently in the dls master branch, and I need to fix a few other things, but a new release should be coming very soon. It's still going to take time to build, but the next version should build properly.
Re: [DUB][DLS] building package dls doesn't finish
On Friday, 11 May 2018 at 22:56:09 UTC, Kamil Koczurek wrote: On Friday, 11 May 2018 at 01:00:31 UTC, Rubn wrote: On Thursday, 10 May 2018 at 09:32:38 UTC, Kamil Koczurek wrote: Hello, I installed an atom extension for D support, but it requires dls package to be installed and built. When I fetch and attempt to build it (with --build=release) it just says that it's building and doesn't change even if I leave it running for several hours. What can I do to fix it? Or do I just leave it overnight? Ps. Sorry if it's a wrong section, it's my first time posting here. Download ldc2 and use --compiler=ldc. DMD's optimization is incredibly slow with O(N!) time depending on what you are doing. Try build the debug build to see if that is the issue. If your debug builds quickly then that was probably the issue. But in general you'd probably want to use LDC for tools you are going to be using. Thanks for reply. It didn't help at all, I just realized it doesn't actually start building dls, it stops while doing something with dependencies. I ran it with -v and that's the last line it gets to: "Return for libddoc: [(long list of versions)]". Here's the full log: https://pastebin.com/1xaAa4VG When it happens dub starts using 100% of one of my CPU cores, guess that might be important. Okay, I thought that it may be a problem on my side so I set up an Ubuntu container with docker and ran just those four commands: - apt update - apt install dub - dub fetch dls - dub build dls -v And got an almost identical result, but this time at the and dub also printed the following: The dependency resolution process is taking too long. The dependency graph is likely hitting a pathological case in the resolution algorithm. Please file a bug report at https://github.com/dlang/dub/issues and mention the package recipe that reproduces this error. Guess I'll just report it. Not sure if I should notify people maintaining dls too though.
Re: Sealed classes - would you want them in D?
On 5/11/2018 4:28 PM, Jonathan M Davis wrote: [...] See my reply to H. S. Teoh.
Re: Sealed classes - would you want them in D?
On 5/11/2018 4:27 PM, H. S. Teoh wrote:
On Fri, May 11, 2018 at 04:14:43PM -0700, Walter Bright via Digitalmars-d wrote:
On 5/10/2018 6:22 AM, Piotr Mitana wrote:
For those who never coded Scala and don't know sealed classes: a
sealed class is a class which can be only extended in the same
source file.
sealed class MyClass {}
Translating to D, a sealed class would could only be extended in the
same module.
private class MyClass { }
should do the trick.
It doesn't; if you do this, you can't pass MyClass outside the module
and have other modules invoke its methods. They will get an essentially
opaque object. You'll have to resort to ugly wrapper types (defined in
the same module) in order to make this work.
The solution is:
private class MyClass { ... }
public final MyClassSealed : MyClass { }
Meaning other modules can use MyClassSealed but cannot derive from it. Other
classes inside the module can derive from MyClass as required.
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 07:07:33 UTC, Jonathan M Davis wrote: You obviously don't have to test your private functions if you don't want to, but if you're trying to state that testing private functions is bad practice (and that's very much what it seemed like you were saying when you talked about testing private functions killing unicorns), [...] Actually Jim Weirich (Rake's creator) at one of Ruby's conferences had a coffee mug with "Every time you test a private method, an unicorn dies".
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 07:39:04 UTC, Jonathan M Davis wrote: Ultimately, it's a tradeoff, and arguments can be made for and against. But in practice, it works extremely well. You're certainly free to not like this particular design choice, but it's one that most of us have no problem with, and I'd be shocked to ever see it change. So, you can be unhappy about it, but complaining isn't going to change anything. You're either going to have to just learn to live with it or not use D. - Jonathan M Davis I'm not so much complaining about it, as warning others of it. D modules do NOT (cannot) respect the encapsulation of the class, and therefore, D modules containing classes, can very easily (to borrow a phrase from Bertrand Meyer) start to resemble "a chunk of Swiss cheese that has been left outside for too long..". As for using D, this is why I don't really use D for anything other than small tasks - where I can happily revert to procedural type programming ( C like), and not have to worry about the issues of broken class encapsulation - which will almost certainly lead to unexpected side-effects, and create whole new 'class' of problems that D programmers have to deal with.
Re: Sealed classes - would you want them in D?
On Saturday, May 12, 2018 07:29:47 KingJoffrey via Digitalmars-d wrote: > On Saturday, 12 May 2018 at 07:19:47 UTC, rikki cattermole wrote: > > I see no problem. > > > > onlineapp.d(1): Error: label wtf is undefined > > The 'Error' is my point. It's not possible to do this - which is > a good thing. > > D protects the encapsulation unit of the function from such abuse. > > But the same is not true for classes. You could argue the same of friend functions in C++. Yes, D weakens the encapsulation of classes in comparison to C++, but it simplifies the language in comparison to needing friend functions like C++ does, and it works _really_ well with stuff like unit testing. Other languages are forced to do stuff like have member functions and variables be protected just so that you can have a unit testing class access them via inheritance, whereas D avoids the need to change the class' API just to be able to test it, because the module has full access to it. Ultimately, it's a tradeoff, and arguments can be made for and against. But in practice, it works extremely well. You're certainly free to not like this particular design choice, but it's one that most of us have no problem with, and I'd be shocked to ever see it change. So, you can be unhappy about it, but complaining isn't going to change anything. You're either going to have to just learn to live with it or not use D. - Jonathan M Davis
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 07:19:47 UTC, rikki cattermole wrote: I see no problem. onlineapp.d(1): Error: label wtf is undefined The 'Error' is my point. It's not possible to do this - which is a good thing. D protects the encapsulation unit of the function from such abuse. But the same is not true for classes.
Re: Sealed classes - would you want them in D?
On 12/05/2018 7:07 PM, KingJoffrey wrote:
On Saturday, 12 May 2018 at 06:38:16 UTC, rikki cattermole wrote:
Now move Person into its own module.
Boom errors.
This is how module systems should work and everything is working
correctly :)
You will not convince us otherwise.
If D treated functions, like it treats classes, then you could do this
in D (see below) - and the argument to get around the problems this
causes, would be to put each individual function in it's own module.
That is in essence, your proposed solution to the problem with class
encapsulation in D.
module test;
void main() { goto wtf; }
void foo()
{
wtf: return;
return;
}
==
I see no problem.
onlineapp.d(1): Error: label wtf is undefined
Re: Sealed classes - would you want them in D?
On Saturday, 12 May 2018 at 06:38:16 UTC, rikki cattermole wrote:
Now move Person into its own module.
Boom errors.
This is how module systems should work and everything is
working correctly :)
You will not convince us otherwise.
If D treated functions, like it treats classes, then you could do
this in D (see below) - and the argument to get around the
problems this causes, would be to put each individual function in
it's own module.
That is in essence, your proposed solution to the problem with
class encapsulation in D.
module test;
void main() { goto wtf; }
void foo()
{
wtf: return;
return;
}
==
Re: Sealed classes - would you want them in D?
On Saturday, May 12, 2018 06:42:24 rumbu via Digitalmars-d wrote:
> On Friday, 11 May 2018 at 20:22:52 UTC, H. S. Teoh wrote:
> > On Fri, May 11, 2018 at 02:04:34PM -0600, Jonathan M Davis via
> >
> > Digitalmars-d wrote:
> >> On Friday, May 11, 2018 19:45:10 rumbu via Digitalmars-d wrote:
> > [...]
> >
> >> > The first example is unit testing. Having access to the
> >> > private members of a class inside the same module is a
> >> > mistake because it breaks the idea of encapsulation. Unit
> >> > testing must be done exclusively on public members of a
> >> > class. If you are feeling the urge to test a class private
> >> > thing, there is something wrong with your class design. In
> >> > the parallel world of true OOP which D tries to avoid as
> >> > much as possible there is a saying for that: "Everytime you
> >> > test a private method, a unicorn dies".
> >>
> >> I completely disagree with this. Testing private functions can
> >> be extremely valuable for ensuring that everything within the
> >> type functions the way that it should and can often lead to
> >> much better testing of how pieces of a type work, because you
> >> have better control over what's going on at that exact point
> >> in the call chain when you're testing it directly.
> >
> > Yeah, in my own projects I have found that unittesting private
> > functions has been a life-saver in catching bugs early
> > (especially if you're writing a complex class / struct / type /
> > module with many moving parts), ensuring helper functions
> > actually work, and also building confidence that the code is
> > actually doing what you think it's doing. Testing only the
> > external API means I have to write a ton of code before a
> > single test can be run, which means a lot more places for bugs
> > to hide and a lot more time wasted trying to locate a bug
> > buried deep within several levels of function calls under the
> > public API.
> >
> > If it's true that a unicorn dies everytime I test a private
> > method, then I say, kill 'em all off, they deserve to go
> > extinct!
> >
> > (None of this negates the fact that public APIs need to be
> > thoroughly tested, of course. Like Jonathan, I just don't see
> > how one could argue that private methods should *not* be
> > tested.)
> >
> >
> > T
>
> I never said that. Feel free to test your private methods as long
> as you want it if you think that will improve your code
> correctness. But for *me* this is a bad practice. Every time I am
> in a situation that will result in such need, I question myself
> if there is something wrong with my class design and usually I
> end with extracting that private functionality to another class
> that can be tested.
>
> Testing private functionality means that you *lock* the internal
> implementation of your class. If you decide later to change the
> implementation, your previous tests will have zero-value.
>
> On the contrary, testing public functionality of a class will
> *lock* the design and this is desirable at least from a library
> design point of view.
>
> The difference here is that D is offering you the means to code
> your stuff exactly as you want it, but the same is not true for
> my way of coding. And this is really annoying when you are doing
> TDD where the public testing of a class is in fact the definition
> of functionality and I don't want to touch by mistake any private
> member in the process.
>
> class SquareRoot
> {
>private void someComplicatedAlgorithm { ... }
>public void calculate() { ... someComplicatedAlgorithm() ... }
> }
>
> unittest
> {
>//assert something about someComplicatedAlgorithm
>//and so on.
> }
>
>
> Let's suppose that one day I will change someComplicatedAlgorithm
> and most of the assertions will not be satisfied. That moment I
> have two options: modify all my assertions to match or completely
> delete them, hence the zero-value of them.
>
> It will not be better to limit my assertions to calculate()
> instead?
That's your choice, but even if you decided to refactor in a way that it
made sense to throw away all of the tests for a private function, at least
it was well-tested up to that point, and the tests had value as long as they
made sense. Personally, I would _much_ rather be very thorough with my tests
and then later have to seriously rework existing tests or throw them away
when I refactor than to not have thorough testing. And my experience is that
if a private function is anything other than really short and simple, having
tests for it catches bugs and improves the quality of my code, regardless of
whatever refactoring I may or may not do later.
You obviously don't have to test your private functions if you don't want
to, but if you're trying to state that testing private functions is bad
practice (and that's very much what it seemed like you were saying when you
talked about testing private functions killing unicorns), then I'm very much
going to disagree - especially in cases where the public
