Re: How often I should be using const? Is it useless/overrated?
So the answer to your question is, use it when it has a payoff - for you. If that's the case, I've probably come to my own conclusion: that it's not worth it as it's not giving me any payoff for the extra code. Thanks.
Re: How often I should be using const? Is it useless/overrated?
On Tuesday, 22 November 2022 at 23:30:38 UTC, thebluepandabear
wrote:
On Tuesday, 22 November 2022 at 22:40:54 UTC, []() {}() wrote:
On Friday, 18 November 2022 at 11:51:42 UTC, thebluepandabear
wrote:
As a newcomer, I'd be interested in hearing everyones
thoughts.
Everyones thoughts? You sure about that ;-)
anyho
To Const or Not to Const?
https://www.artima.com/articles/const-rtti-and-efficiency
C++ const is different than D const, not sure how helpful that
article is.
Yes, that is true (about the differences).
But Scott is very specific about it not being langauge specific.
His guidelines are engineering guidelines.
e.g. "You're saying in your experience, the cost of the policy to
type const all those times just doesn't pay for itself. If that's
been your experience, then that's fine."
In other words, he is saying, the decision to use const or not,
is a tradeoff.
Software engineers make tradeoffs, all the time. It comes with
package.
So the answer to your question is, use it when it has a payoff -
for you.
That's the same answer I gave to you for getters/setters ;-)
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 10:10:48 UTC, Sergey wrote: .. I saw some posts at forum about private-class-scope, but community of core-D is fine with module-unit approach I think. That's fair enough. I fully support 'majority rules' (if that's what's happening here). But it could limit the uptake of the langauge, particulary for those software engineers who believe that when you are defining a class, you are defining a type - as Scott Myers has put it. To such people, other code in the module shouldn't affect my type, in the same way it shouldn't affect a built-in type. At least, not unless I've authorised it, as part of the specification of my type, which presumably I have, by default, just by including any other code in a module, where a class type has been defined. In such a module, one should annotate the class with @hereBeDragons
Re: How often I should be using const? Is it useless/overrated?
On Tuesday, 22 November 2022 at 22:40:54 UTC, []() {}() wrote:
On Friday, 18 November 2022 at 11:51:42 UTC, thebluepandabear
wrote:
As a newcomer, I'd be interested in hearing everyones thoughts.
Everyones thoughts? You sure about that ;-)
anyho
To Const or Not to Const?
https://www.artima.com/articles/const-rtti-and-efficiency
C++ const is different than D const, not sure how helpful that
article is.
Re: How often I should be using const? Is it useless/overrated?
On Friday, 18 November 2022 at 11:51:42 UTC, thebluepandabear wrote: As a newcomer, I'd be interested in hearing everyones thoughts. Everyones thoughts? You sure about that ;-) anyho To Const or Not to Const? https://www.artima.com/articles/const-rtti-and-efficiency
Re: Can't assign extern(C) function pointer to D variable?
On Tuesday, 22 November 2022 at 21:32:43 UTC, Hipreme wrote:
You need to create an alias containing your callback type.
Thanks both!! I have all the pieces of the puzzle. I'm actually
staying with the wrapping template solution. (Because the
strongly typed one turns out too convoluted, and because it
allows the remaining ScopeCleanup struct to be more general
purpose, for non-C functions, and for functions that don't return
void but an error code which I want to discard.)
The first problem was indeed that a C function pointer "is not" a
D one. So annotating the variable with extern(C) can indeed solve
it. I had actually tried this, but it was not compiling for
another reason.
The next reason (as you see in the GitHub link) is that the
variable in question is a (constructor) parameter. D can't seem
to compile extern(C) inlined somewhere else.
Indeed aliasing takes care of this second problem:
alias CFunction = extern(C) void function();
/// RAII object that does nothing but calling, when destructed,
the function passed at construction.
struct ScopeCleanup
{
@disable this();
this(CFunction cleanup) { this.cleanup = cleanup; }
~this() { cleanup(); }
CFunction cleanup;
}
Now this module compiles. BUT the code trying to call this
constructor doesn't compile, when called with C function such as
SDL_Quit imported from the SDL lib, or IMG_Quit imported from the
SDL_image lib.
From the compiler error I learn that the imported function is not
only extern(C) but also nothrow @nogc. Fair enough, I add it to
the alias. BUT still no good, because (as I learn from the same
compiler error) this binding imports these functions as
extern(C) void function() nothrow @nogc*
with this final "*" this turns out, from the D point of view, a
"pointer to a function pointer" XD so it has to be
called/de-referenced in this way (in destructor):
alias CFunctionPtr = extern(C) void function() nothrow @nogc*;
/// RAII object that does nothing but calling, when destructed,
the function passed at construction.
struct ScopeCleanup
{
@disable this();
this(CFunctionPtr cleanup) { this.cleanup = cleanup; }
~this() { (*cleanup)(); }
CFunctionPtr cleanup;
}
Thanks guys for the learning, I'm staying with the template
solution (thanks D), but let me know if you have more insights.
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 21:00:58 UTC, []() {}() wrote:
"Being able to declare a “friend” that is somewhere in some other
file runs against notions of encapsulation." (This is the
motivation for that article it seems).
I completely disagree with the assertion.
C++ Friend notion does not, not by any means, run against the
notion of encapsulation.
Sure, it expands the perimeter (i.e. it puts a door in the wall).
But, and this is my point, there is a guard standing at the door.
And that guard knows who has been authorised to pass through it.
The encapsulation remains. Only its perimeter has been expanded.
One could argue that D's approach is just that. It expands the
perimeter to the module level. But there's no guard at the door
in D.
Surely, this 'let anyone pass through' design, decreases
encapsulation? How could it possibly increase encapsulation, as
claimed, by the author of that article?
If there were a means in the language for controlled sharing
within a module, *that* would increase encapsulation.
Re: Can't assign extern(C) function pointer to D variable?
On 22.11.22 22:11, XavierAP wrote: I was surprised when it didn't compile, though I immediately found it understandable... Already read through https://dlang.org/spec/interfaceToC.html and https://wiki.dlang.org/Bind_D_to_C Is it really the case (that an extern(C) function pointer cannot be assigned to a D variable)? Or is it a matter of annotating with the right attributes? If so, how? Works for me: import core.stdc.stdio: puts; auto p1 = extern (C) int function(const char* s) p2 = If you're trying to assign an `extern (C)` function pointer to an `extern (D)` one (the default), that cannot work. The compiler would emit code using D's calling convention, but the called function would assume C's calling convention.
Re: Can't assign extern(C) function pointer to D variable?
On Tuesday, 22 November 2022 at 21:11:37 UTC, XavierAP wrote: I was surprised when it didn't compile, though I immediately found it understandable... Already read through https://dlang.org/spec/interfaceToC.html and https://wiki.dlang.org/Bind_D_to_C [...] You need to create an alias containing your callback type. ```d alias DCallback = extern(C) void function(); DCallback cb; cb = yourCFunction; ```
Can't assign extern(C) function pointer to D variable?
I was surprised when it didn't compile, though I immediately found it understandable... Already read through https://dlang.org/spec/interfaceToC.html and https://wiki.dlang.org/Bind_D_to_C Is it really the case (that an extern(C) function pointer cannot be assigned to a D variable)? Or is it a matter of annotating with the right attributes? If so, how? Otherwise I'm interested in the best or most concise workaround. Is there a better one? I came up with a template solution: https://github.com/XavierAP/game-king/blob/master/source/scope_cleanup.d The problem I had was that this ScopeCleanup struct could not be constructed passing a pointer to a function imported from C (from the SDL library; you can browse around the same repo to see its usage; it's just a toy project that's barely started).
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 20:36:51 UTC, []() {}() wrote:
From a software engineering perspective, what justification can
their possibly be, for allowing (by default, and with no language
mechanism to prevent it) any code in the same module as this
class (including a tightly coupled, but otherwise fully
specificed class), to override the specification of this class?
How does that enhance encapsulation, as argued in that article?
public synchronized class Counter
{
static import core.atomic;
private:
int count = 0;
public:
void incrementCounter()
{
if ((count + 1) < 0)
{
// you might want to handle this
}
else
core.atomic.atomicOp!"+="(this.count, 1);
}
int displayCounter()
{
return count;
}
}
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 10:10:48 UTC, Sergey wrote: Based on this (not too old) post the idea remains the same and approved by Walter’s experience: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ I saw some posts at forum about private-class-scope, but community of core-D is fine with module-unit approach I think. In the interest of 'critical thinking', it's important to point out, that one of the persons in this thread agreeing with the one-sided rant in the video link in this thread, is a co-author of that article. It also seems, that article is primarly discussing encapsulation. Encapsulation is not enough, as I've pointed out in this thread. In D, one can no longer provide a static specification of a class type, let alone rely on the compiler to assure you of the correctness of that specification, in relation to the code surrounding it). Rather, in D, one must always include all the code in the module as being part of the static specification of the class (and the same is true for how ever many classes you have in that module). Even another class could form part of the specification of another class in the same module, even though they are both concrete classes. Wow! I'm sorry, but that makes no sense to me. The designers of the other languages mentioned in that article, seem to have the same opinion. Whatever happened to the principle of least priveledge in D? Of course, if you're against the us of private, against the use of getters and setters, and against the use of classes, in D, then sure, I can fully understand the decision to completely remove the perimeter for a class type, and hence that article makes complete sense. Regardless, I fully support the concept that people should always form their own opinion - even on matters as absurd as this ;-)
Re: How often I should be using const? Is it useless/overrated?
On Friday, 18 November 2022 at 11:51:42 UTC, thebluepandabear wrote: A question I have been thinking about whilst using D is how often I should be using const. Many people claim that all variables should be const by default, but whether or not it is really needed is debatable and oftentimes making everything const could cause readability issues and make the code more complex. I also wonder how important const really is, like 99% of the time you will know when your variable will be changed, and even when a variable changes it's not like it is the end of the world. Also, there is no real end to how much variables can be const. Oftentimes -- interestingly -- in popular repos I don't even see const being used, this is what confuses me. As a newcomer, I'd be interested in hearing everyones thoughts. IMHO and besides other insights in previous replies, in practice this depends on whether you're talking about private implementation code, or an external interface -- of a library, component/unit (under test), etc. In private implementation code, including your scripts, informal code for personal use etc. you should probably not bother more than needed. It's fine that other languages (functional or safety-paranoid) force const or immutable by default, it's fine that D doesn't. Go with the least verbose default for this kind of code. For external interfaces, be mindful that everything that should not be mutated across them, is annotated as const, since languages D or C++ provide this facility. Otherwise you'd have to rely and unsafely trust on naming conventions like Python.
Re: How often I should be using const? Is it useless/overrated?
On Friday, 18 November 2022 at 17:57:25 UTC, H. S. Teoh wrote: You're looking at it the wrong way. The kind of issues having const would solve is like when your function takes parameters x, y, z, and somewhere deep in the function you see the expression `x + y*z`. If x, y, and z are const, then you immediately know what the value of this expression is. However, if they were not, then you'd have to trace through all of the preceding code to figure out whether their values have changed, and how they have changed. The former makes the code easier to understand, the latter adds complexity to understanding the code. AFAIK Rust allows shadowing (intentionally) to solve usability problems with immutable variables, so when deep in the function you see `x+y*z`, you can't immediately tell its value, because the variables could be previously shadowed and you have to trace through all of the preceding code to figure it out :)
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 03:04:03 UTC, []() {}() wrote:
On Tuesday, 22 November 2022 at 02:16:16 UTC, []() {}() wrote:
nevermind ;-) .. seems clear nobody wants something like this
in D.
https://forum.dlang.org/post/kbl20f$2np9$1...@digitalmars.com
and... 20 years later ... .. .
Based on this (not too old) post the idea remains the same and
approved by Walter’s experience:
https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
I saw some posts at forum about private-class-scope, but
community of core-D is fine with module-unit approach I think.
Re: "Little Scheme" and PL Design (Code Critique?)
On Thursday, 17 November 2022 at 22:05:45 UTC, jwatson-CO-edu wrote: I just pushed a D implementation of "[Little Scheme](https://mitpress.mit.edu/9780262560993/the-little-schemer/)", which is a limited educational version of [Scheme](https://en.wikipedia.org/wiki/Scheme_(programming_language)), to [GitHub](https://github.com/jwatson-CO-edu/SPARROW). [...] I think using the d garbage collector is a good idea. (I have written two implementations of scheme like languages one in c and one in d, and I found it a great pleasure not to have to write a GC for the d one). On the other hand if you want to write one there is no obstruction doing so in d.
