Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 05:42:03 UTC, []() {}() wrote:
those public Get/Set members functions are exactly what you get
in C#, except the compiler does it for you, behind the scenes,
saving you the keystokes.. but the end code is just as if you
had typed them out yourself.
I know...
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 04:47:57 UTC, thebluepandabear
wrote:
https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms229042(v=vs.100)
Thanks, I'll think about it more -- I am a noob so I may be
wrong in what I am saying.
Of course in C# this argument wouldn't exist because you could
just do `{ get; set; }`, and I really wish D had something
similar
It does.
private int myVariable;
public Get_myVariable(){}
public Set_myVariable(){}
those public Get/Set members functions are exactly what you get
in C#, except the compiler does it for you, behind the scenes,
saving you the keystokes.. but the end code is just as if you had
typed them out yourself.
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:52:41 UTC, thebluepandabear wrote: ... . Honestly, it may not be a magic bullet, but still useful. This refactoring may be source compatible, but would it be binary compatible? i.e. you refactor your class, compile it as an updated version of your library, then ship that updated library to your users will they then need to recompile their own code because of the refactoring you did? In C#, I know the answer to that question. As for D, I do not know (and I don't expect you to either ;-)
Re: Is defining get/set methods for every field overkill?
https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms229042(v=vs.100)
Thanks, I'll think about it more -- I am a noob so I may be wrong
in what I am saying.
Of course in C# this argument wouldn't exist because you could
just do `{ get; set; }`, and I really wish D had something
similar
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 04:37:51 UTC, thebluepandabear wrote: Thankfully I only code in D as a hobby, so I don't need to use getters/setters! Thanks. well, in that case, you can throw out everything that programmers have learnt over many decades, and just to whatever you want in your code. But if you ever want to have users of your TUI Library, or want to have other developers contribute to it, you will want to follow reasonable guidelines. Here is an example of a reasonable guideline (For C#, but can easily apply to D): https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms229042(v=vs.100)
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 04:27:14 UTC, []() {}() wrote:
On Saturday, 19 November 2022 at 04:19:01 UTC, thebluepandabear
wrote:
oh. so i get it now. you have to refactor your class (change
member variable names and also do it in all places where they
are used througout the class. then add new methods,
overloading them in this way and that way, all because you're
initial design never factored in the possibility of change
(or even some validation of the vale being returned to the
client, or validation of value coming from the client).
after 10 years of doing all that, you may well come to the
conclusion that public member variables are not such a great
idea afterall ;-)
These days with modern IDEs it takes a second to change the
name of a variable globally. In production level code, it may
take more time, but I doubt by a lot.
Think about it, if you have a class with 20 different
variables that don't need any special rules to access, think
about the amount of code you would have to add for
getters/setters. Now in production level code you will have
thousands of these classes, and as such you will have a good
chunk of code that is practically useless and doing nothing.
By making your class member variables public, it is not clear
whether you forgot that you needed to validate incoming and
outgoing values, or whether you don't need to do this (not
ever).
If you did it because of the former, you're fired ;-)
If you did it because of the latter, you're also fired ;-)
Thankfully I only code in D as a hobby, so I don't need to use
getters/setters! Thanks.
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 04:19:01 UTC, thebluepandabear wrote: oh. so i get it now. you have to refactor your class (change member variable names and also do it in all places where they are used througout the class. then add new methods, overloading them in this way and that way, all because you're initial design never factored in the possibility of change (or even some validation of the vale being returned to the client, or validation of value coming from the client). after 10 years of doing all that, you may well come to the conclusion that public member variables are not such a great idea afterall ;-) These days with modern IDEs it takes a second to change the name of a variable globally. In production level code, it may take more time, but I doubt by a lot. Think about it, if you have a class with 20 different variables that don't need any special rules to access, think about the amount of code you would have to add for getters/setters. Now in production level code you will have thousands of these classes, and as such you will have a good chunk of code that is practically useless and doing nothing. By making your class member variables public, it is not clear whether you forgot that you needed to validate incoming and outgoing values, or whether you don't need to do this (not ever). If you did it because of the former, you're fired ;-) If you did it because of the latter, you're also fired ;-)
Re: Is defining get/set methods for every field overkill?
classes, and as such you will have a good chunk of code that is practically useless and doing nothing. Meant *fields not variables, excuse my terminology.
Re: Is defining get/set methods for every field overkill?
oh. so i get it now. you have to refactor your class (change member variable names and also do it in all places where they are used througout the class. then add new methods, overloading them in this way and that way, all because you're initial design never factored in the possibility of change (or even some validation of the vale being returned to the client, or validation of value coming from the client). after 10 years of doing all that, you may well come to the conclusion that public member variables are not such a great idea afterall ;-) These days with modern IDEs it takes a second to change the name of a variable globally. In production level code, it may take more time, but I doubt by a lot. Think about it, if you have a class with 20 different variables that don't need any special rules to access, think about the amount of code you would have to add for getters/setters. Now in production level code you will have thousands of these classes, and as such you will have a good chunk of code that is practically useless and doing nothing.
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:52:41 UTC, thebluepandabear
wrote:
On Saturday, 19 November 2022 at 03:39:18 UTC, []() {}() wrote:
On Saturday, 19 November 2022 at 03:22:12 UTC,
thebluepandabear wrote:
On Saturday, 19 November 2022 at 03:19:53 UTC, []() {}()
wrote:
On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote:
..
D has far less need for getters/setters than Java or C++.
The reason is [Uniform Function Call
Syntax](https://ddili.org/ders/d.en/ufcs.html). This means
that a member of a `struct` or `class` can start out as a
normal field and be later converted to getter/setter if
needed, without breaking calling code.
..
can you give an example please.
i.e. before (class with public member) and after ( i.e. that
public member converted to getter/setter).
Did you read the link provided? There's examples there...
it's say for member functions, not member variables.
I read it, but I dont get the point was being made about how
use ufcs to convert a public member variable of a class type
into a getter and setter. Was there an example in the link
that I missed?
It's actually kind of hard to wrap my head around.
I will try to give you an example as to how you could convert a
field into a getter/setter without breaking the interface
between the user of the library, though it does require code
refactoring on your end.
Say you have the class Rect2D:
```
class Rect2D {
int width;
int height;
}
```
The users of your class would use it like so:
```
Rect2D rect = new Rect2D();
rect.width = 5;
rect.height = 5;
```
Say you want to write 'SET' now whenever someone sets a
width/height value for the rect (as an example), and 'GET' when
someone gets the width/height value for the rect, what you
could do is do this:
```
class Rect2D {
int rectWidth;
int rectHeight;
int width() {
writeln("GET");
return rectWidth;
}
void width(int rectWidth) {
writeln("SET");
this.rectWidth = rectWidth;
}
int height() {
writeln("GET");
return rectHeight;
}
void height(int rectHeight) {
writeln("SET");
this.rectHeight = rectHeight;
}
}
```
Honestly, it may not be a magic bullet, but still useful.
oh. so i get it now. you have to refactor your class (change
member variable names and also do it in all places where they are
used througout the class. then add new methods, overloading them
in this way and that way, all because you're initial design never
factored in the possibility of change (or even some validation of
the vale being returned to the client, or validation of value
coming from the client).
after 10 years of doing all that, you may well come to the
conclusion that public member variables are not such a great idea
afterall ;-)
Re: Is defining get/set methods for every field overkill?
If you only want to add setters:
```
class Rect2D {
int _width;
int _height;
void width(int width) {
writeln("SET");
this._width = width;
}
void height(int height) {
writeln("SET");
this._height = height;
}
}
```
Re: Is defining get/set methods for every field overkill?
A better example of a code refactor after adding getters/setters
is changing the names of the fields like so:
```
class Rect2D {
int _width;
int _height;
```
or
```
class Rect2D {
int width_;
int height_;
```
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:52:41 UTC, thebluepandabear
wrote:
On Saturday, 19 November 2022 at 03:39:18 UTC, []() {}() wrote:
On Saturday, 19 November 2022 at 03:22:12 UTC,
thebluepandabear wrote:
On Saturday, 19 November 2022 at 03:19:53 UTC, []() {}()
wrote:
On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote:
..
D has far less need for getters/setters than Java or C++.
The reason is [Uniform Function Call
Syntax](https://ddili.org/ders/d.en/ufcs.html). This means
that a member of a `struct` or `class` can start out as a
normal field and be later converted to getter/setter if
needed, without breaking calling code.
..
can you give an example please.
i.e. before (class with public member) and after ( i.e. that
public member converted to getter/setter).
Did you read the link provided? There's examples there...
it's say for member functions, not member variables.
I read it, but I dont get the point was being made about how
use ufcs to convert a public member variable of a class type
into a getter and setter. Was there an example in the link
that I missed?
It's actually kind of hard to wrap my head around.
I will try to give you an example as to how you could convert a
field into a getter/setter without breaking the interface
between the user of the library, though it does require code
refactoring on your end.
Say you have the class Rect2D:
```
class Rect2D {
int width;
int height;
}
```
The users of your class would use it like so:
```
Rect2D rect = new Rect2D();
rect.width = 5;
rect.height = 5;
```
Say you want to write 'SET' now whenever someone sets a
width/height value for the rect (as an example), and 'GET' when
someone gets the width/height value for the rect, what you
could do is do this:
```
class Rect2D {
int rectWidth;
int rectHeight;
int width() {
writeln("GET");
return rectWidth;
}
void width(int rectWidth) {
writeln("SET");
this.rectWidth = rectWidth;
}
int height() {
writeln("GET");
return rectHeight;
}
void height(int rectHeight) {
writeln("SET");
this.rectHeight = rectHeight;
}
}
```
Honestly, it may not be a magic bullet, but still useful.
The only caveat (and I am a noob to D, so don't take any sort of
advice from me seriously, please) seems to be that you just need
to change the field name on your end.
Re: Need Advice: Union or Variant?
On Saturday, 19 November 2022 at 03:38:26 UTC, jwatson-CO-edu
wrote:
Thank you, something similar to what you suggested reduced the
atom size from 72 bytes to 40.
Oh, based on another forum post I added constructors in addition
to reducing the atom size 44%.
```d
struct Atom{
F_Type kind; // What kind of atom this is
union{
double num; // NMBR: Number value
string str; // STRN: String value, D-string
boolbul; // BOOL: Boolean value
struct{ // CONS: pair
Atom* car; // Left `Atom` Pointer
Atom* cdr; // Right `Atom` Pointer
}
struct{ // EROR: Code + Message
F_Error err; // Error code
string msg; // Detailed desc
}
}
// https://forum.dlang.org/post/omsbr8$7do$1...@digitalmars.com
this( double n ){ kind = F_Type.NMBR; num = n; } // make
number
this( string s ){ kind = F_Type.STRN; str = s; } // make
string
this( bool b ){ kind = F_Type.BOOL; bul = b; } // make bool
this( Atom* a, Atom* d ){ kind = F_Type.CONS; car = a; cdr =
d; } // make cons
this( F_Error e, string m ){ kind = F_Type.EROR; err = e; msg
= m; } // make error
}
```
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:39:18 UTC, []() {}() wrote:
On Saturday, 19 November 2022 at 03:22:12 UTC, thebluepandabear
wrote:
On Saturday, 19 November 2022 at 03:19:53 UTC, []() {}() wrote:
On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote:
..
D has far less need for getters/setters than Java or C++.
The reason is [Uniform Function Call
Syntax](https://ddili.org/ders/d.en/ufcs.html). This means
that a member of a `struct` or `class` can start out as a
normal field and be later converted to getter/setter if
needed, without breaking calling code.
..
can you give an example please.
i.e. before (class with public member) and after ( i.e. that
public member converted to getter/setter).
Did you read the link provided? There's examples there...
it's say for member functions, not member variables.
I read it, but I dont get the point was being made about how
use ufcs to convert a public member variable of a class type
into a getter and setter. Was there an example in the link that
I missed?
It's actually kind of hard to wrap my head around.
I will try to give you an example as to how you could convert a
field into a getter/setter without breaking the interface between
the user of the library, though it does require code refactoring
on your end.
Say you have the class Rect2D:
```
class Rect2D {
int width;
int height;
}
```
The users of your class would use it like so:
```
Rect2D rect = new Rect2D();
rect.width = 5;
rect.height = 5;
```
Say you want to write 'SET' now whenever someone sets a
width/height value for the rect (as an example), and 'GET' when
someone gets the width/height value for the rect, what you could
do is do this:
```
class Rect2D {
int rectWidth;
int rectHeight;
int width() {
writeln("GET");
return rectWidth;
}
void width(int rectWidth) {
writeln("SET");
this.rectWidth = rectWidth;
}
int height() {
writeln("GET");
return rectHeight;
}
void height(int rectHeight) {
writeln("SET");
this.rectHeight = rectHeight;
}
}
```
Honestly, it may not be a magic bullet, but still useful.
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:24:41 UTC, thebluepandabear wrote: I think because of uniform function call syntax, getters/setters are not needed even for production level code, in D of course. In Java, you do need them so your point holds true in that scenario, but in D I don't really see the point after giving it some thought, I would say they are code bloat. I like to see an example, of a 'class type' with 'public' member variables, somehow magically converted into both getter and setter using UFCS, without breaking client code.
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:22:12 UTC, thebluepandabear
wrote:
On Saturday, 19 November 2022 at 03:19:53 UTC, []() {}() wrote:
On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote:
..
D has far less need for getters/setters than Java or C++. The
reason is [Uniform Function Call
Syntax](https://ddili.org/ders/d.en/ufcs.html). This means
that a member of a `struct` or `class` can start out as a
normal field and be later converted to getter/setter if
needed, without breaking calling code.
..
can you give an example please.
i.e. before (class with public member) and after ( i.e. that
public member converted to getter/setter).
Did you read the link provided? There's examples there...
it's say for member functions, not member variables.
I read it, but I dont get the point was being made about how use
ufcs to convert a public member variable of a class type into a
getter and setter. Was there an example in the link that I missed?
Re: Need Advice: Union or Variant?
On Thursday, 17 November 2022 at 22:49:37 UTC, H. S. Teoh wrote:
Just create a nested anonymous struct, like this:
struct Atom {
F_Type kind;
union { // anonymous union
struct {
Atom* car; // - Left `Atom`
Pointer
Atom* cdr; // - Right `Atom`
Pointer
}
struct {
double num; // - Number value
string str; // - String value, D-string
underlies
}
boolbul; // - Boolean value
}
F_Error err = F_Error.NOVALUE; // Error code
}
T
Thank you, something similar to what you suggested reduced the
atom size from 72 bytes to 40.
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:19:53 UTC, []() {}() wrote:
On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote:
..
D has far less need for getters/setters than Java or C++. The
reason is [Uniform Function Call
Syntax](https://ddili.org/ders/d.en/ufcs.html). This means
that a member of a `struct` or `class` can start out as a
normal field and be later converted to getter/setter if
needed, without breaking calling code.
..
can you give an example please.
i.e. before (class with public member) and after ( i.e. that
public member converted to getter/setter).
Did you read the link provided? There's examples there...
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:14:18 UTC, []() {}() wrote:
On Saturday, 19 November 2022 at 03:08:05 UTC, thebluepandabear
wrote:
It likely already does something, in that- >'it allows for
change to occur without having to break the clients
interface'.
That too is the 'point' missing from that rant.
With all due respect, I think your point is mostly invalid due
to the point that Dukc made.
keep programming/maintaining and enhancing production-level
code for the next 10 years.
then you too will know the correct answer to your question :-)
I think because of uniform function call syntax, getters/setters
are not needed even for production level code, in D of course. In
Java, you do need them so your point holds true in that scenario,
but in D I don't really see the point after giving it some
thought, I would say they are code bloat.
Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote: .. D has far less need for getters/setters than Java or C++. The reason is [Uniform Function Call Syntax](https://ddili.org/ders/d.en/ufcs.html). This means that a member of a `struct` or `class` can start out as a normal field and be later converted to getter/setter if needed, without breaking calling code. .. can you give an example please. i.e. before (class with public member) and after ( i.e. that public member converted to getter/setter).
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:08:05 UTC, thebluepandabear wrote: It likely already does something, in that- >'it allows for change to occur without having to break the clients interface'. That too is the 'point' missing from that rant. With all due respect, I think your point is mostly invalid due to the point that Dukc made. keep programming/maintaining and enhancing production-level code for the next 10 years. then you too will know the correct answer to your question :-)
Re: Is defining get/set methods for every field overkill?
It likely already does something, in that- >'it allows for change to occur without having to break the clients interface'. That too is the 'point' missing from that rant. With all due respect, I think your point is mostly invalid due to the point that Dukc made.
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 03:04:41 UTC, thebluepandabear wrote: On Saturday, 19 November 2022 at 00:25:57 UTC, Gavin Ray wrote: On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote: D has far less need for getters/setters than Java or C++. The reason is [Uniform Function Call Syntax](https://ddili.org/ders/d.en/ufcs.html). This means that a member of a `struct` or `class` can start out as a normal field and be later converted to getter/setter if needed, without breaking calling code. This is a great point that I actually had never considered. If you need to swap out the implementation details later, you haven't actually locked yourself in to exposing the raw member because you swap it with a getter function/property of the same name. Huh. I love D. Interesting point. If that's the case, I'd say getters/setters are mostly just code bloat. *in most circumstances where no special behavior is needed btw
Re: Is defining get/set methods for every field overkill?
On Saturday, 19 November 2022 at 00:25:57 UTC, Gavin Ray wrote: On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote: D has far less need for getters/setters than Java or C++. The reason is [Uniform Function Call Syntax](https://ddili.org/ders/d.en/ufcs.html). This means that a member of a `struct` or `class` can start out as a normal field and be later converted to getter/setter if needed, without breaking calling code. This is a great point that I actually had never considered. If you need to swap out the implementation details later, you haven't actually locked yourself in to exposing the raw member because you swap it with a getter function/property of the same name. Huh. I love D. Interesting point. If that's the case, I'd say getters/setters are mostly just code bloat.
Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 09:52:11 UTC, Dukc wrote: D has far less need for getters/setters than Java or C++. The reason is [Uniform Function Call Syntax](https://ddili.org/ders/d.en/ufcs.html). This means that a member of a `struct` or `class` can start out as a normal field and be later converted to getter/setter if needed, without breaking calling code. This is a great point that I actually had never considered. If you need to swap out the implementation details later, you haven't actually locked yourself in to exposing the raw member because you swap it with a getter function/property of the same name. Huh. I love D.
Re: Is defining get/set methods for every field overkill?
On Friday, 18 November 2022 at 20:18:41 UTC, matheus wrote:
On Friday, 18 November 2022 at 09:42:21 UTC, []() {}() wrote:
...
I think you missed the point of that video very badly.
By the way just a few points from that video:
Around: 2:32 -> "Never ever put in an 'accessor' until it
actually does something...".
ok. But then you've made the member variable a part of the
interface to the client, and if you even need to constrain the
value being assigned to the member, you will have to break that
interface.
In production-level code, it is rare you would allow
unconstrained access to a member variable. Not unheard of, just
rare. And in any case, a simple accessor allows you to do so,
should you're business rules ever change.
You should plan for change, in production-level code. That's the
'point' missing from that rant in that video.
Around: 3:10 -> "If there is an 'accessor' it had better do
something in there...".
It likely already does something, in that- >'it allows for change
to occur without having to break the clients interface'.
That too is the 'point' missing from that rant.
Re: Is defining get/set methods for every field overkill?
On Friday, 18 November 2022 at 09:42:21 UTC, []() {}() wrote:
...
I think you missed the point of that video very badly.
By the way just a few points from that video:
Around: 2:32 -> "Never ever put in an 'accessor' until it
actually does something...".
Around: 3:10 -> "If there is an 'accessor' it had better do
something in there...".
Matheus.
Re: How often I should be using const? Is it useless/overrated?
On Fri, Nov 18, 2022 at 11:51:42AM +, thebluepandabear via Digitalmars-d-learn wrote: A question I have been thinking about whilst using D is how often I should be using const. You should use it as often as you need to use it, and no more. If you don't need to use it, don't use it. 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. 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. Now if you have a variable that's expected to change a lot, like an accumulator of some complex calculation, then it makes no sense to make it const. Just modify it; you already have to understand most of the code to figure out how the value is derived anyway, so having fewer variables would actually make it easier to understand. In this case, using const is just counterproductive. IOW, if const makes your code easier to understand and maintain, then go for it. If you're finding that you have to jump through hoops in order to make your variables const, then probably it's *not* a suitable usage in that case. 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. It totally *can* be the end of the world, if your variable is controlling the launch of nuclear missiles, for example. :-P Having a variable change when you don't expect it to -- that's a frequent source of bugs and hard-to-understand code. Again I say, it depends on what it's being used for. If it's used to hold a logically fixed value (e.g., function argument passed from the caller that logically doesn't change) then you want to use const. But if you're using it to hold a temporary value that's expected to change, then what's the point of jumping through hoops just so you can brag "look, ma! my variables are all const!"? 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. [...] Because, honestly, const in D is a pain. The reason is that D's const, unlike const in C or C++, is transitive, meaning that if some object X is const, then everything X refers to is also automatically const. OT1H this is wonderful: this means the compiler can actually make guarantees about const and enforce it. You cannot just cast it away willy-nilly without invoking UB, so the compiler can make optimizations based on the assumption that some value never changes. OTOH the fact that it's transitive means that even if you have one tiny bit of data 10 hops down the line that you want to modify, you can't do it. This greatly narrows the applicability of const in D. It's physical const, and cannot be made logical const. IME, const in D is mostly applicable to what I call "leaf node" data structures: low-level structures where you're mostly dealing directly with the underlying data or maybe 1-2 levels of abstraction away from the physical data. Once you get past that to higher level code, const quickly becomes a giant pain to work with. You cannot, for example, lazy-initialize const data -- because that means you have to modify it after the reference is already initialized, which is UB. You cannot cache data -- because you need to initialize the data when it's referenced for the first time, and you need to set a flag to indicate that the data is cached so that you don't have to load it again. There are ways of working around this, but they are dirty and annoying to use. In my own code, I rarely bother with const, except for the lowest levels of code: modules that don't depend on anything else, so the scope is easier to control and the number of situations to support is limited enough that workarounds don't generate exponential amounts of boilerplate. In higher-level code I rarely bother with const. It often excludes things you often do with complex code -- like caching, lazy initialization, etc.. And errors with const in high-level code can sometimes be a pain to track down -- you declare something const and some leaf-node module 5 levels of abstraction down fails to compile. Why? You have to chase the code down 5 levels of abstraction to find out. It's just not worth
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. This should be a good read for you: [Is there any real reason to use "const"?](https://forum.dlang.org/post/dkkxcibwdsndbckon...@forum.dlang.org)
How often I should be using const? Is it useless/overrated?
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.
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. Some languages like Kotlin and Rust are const by default, but for languages that are not like D I have always wondered how often you should use const.
Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 09:46:57 UTC, matheus wrote: Food for thought: https://yewtu.be/watch?v=_xLgr6Ng4qQ or https://www.youtube.com/embed/_xLgr6Ng4qQ Matheus. 'Food for thought'? Sure, if you're feeding that to your dog. Public fields in 'class' definitions rarely have place in production level code. How would you enforce the business rules?? Lets say, you have declared a public member variable that is of type int, but must be constrained to be within a particular range of that int? Well, you cannot enforce a business rule like that using a public member variable. The user of your class can easily corrupt you data, because they can access it directly. Well, you enforce a business rule, by making it a private member variable and having a public setter that accepts a value and checks whether it meets the business rule, and only if it does, and only if it does, will that value then be assigned to the member variable. That video link you presented is just dog food. Let your dog think about it. In the meantime, you think about production level code please.
