Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear
wrote:
I am creating a TUI library and I have a class with the
following constant fields:
```
class Label : Renderable {
const string text;
const TextAlignment textAlignment;
const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color)
{
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
I am debating whether or not I should add getter methods to
these properties. On one hand, it will inflate the codebase by
a lot, on the other hand -- in other languages like Java it is
a good practice:
```
class Label : Renderable {
private const string text;
private const TextAlignment textAlignment;
private const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color)
{
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
string getText() const {
return text;
}
TextAlignment getTextAlignment() const {
return textAlignment;
}
Color getColor() const {
return color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
It's not a lot of code that has been added but if you have a
class with say 10 different fields, adding getter methods would
definitely increase the code size by a lot, so what are you
guys thoughts on this?
Obligatory note that boilerplate
https://code.dlang.org/packages/boilerplate exists for just this
reason:
class Label : Renderable {
@ConstRead
private const string text_;
@ConstRead
private const TextAlignment textAlignment_;
@ConstRead
private const Color color_;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions_ = dimensions;
this(text, textAlignment, color);
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
mixin(GenerateFieldAccessors);
mixin(GenerateThis);
}
Re: Is defining get/set methods for every field overkill?
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 ... .. .
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 02:11:20 UTC, []() {}() wrote:
maybe: @complete class
insteadof: @concrete class
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 00:46:34 UTC, Siarhei Siamashka
wrote:
..
The `counter` member variable isn't really protected from rogue
accesses (if these accesses are done by the code in the same
source file) and this behavior differs from C++.
module CounterTest;
//@concrete public synchronized class Counter // if only D
has this property.
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;
}
}
void main()
{
import std;
shared Counter c = new Counter;
for (int i = 0; i < 5; i++)
c.incrementCounter;
c.count = 0; // not if your class is a @concrete class
writeln(c.displayCounter);
}
unittest
{
shared Counter c = new Counter;
c.count = 0; // not if your class is a @concrete class
}
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 00:46:34 UTC, Siarhei Siamashka wrote: On Monday, 21 November 2022 at 23:41:22 UTC, thebluepandabear wrote: But why give a C++ code example? 廊 It's a D code example and it even can't be compiled by a C++ compiler. Just add the missing main function: My bad.
Re: Is defining get/set methods for every field overkill?
On Monday, 21 November 2022 at 23:41:22 UTC, thebluepandabear
wrote:
But why give a C++ code example? 廊
It's a D code example and it even can't be compiled by a C++
compiler. Just add the missing main function:
```D
void main()
{
shared c = new Counter;
c.incrementCounter;
c.count = 12345; // haha, this isn't really private in D
(unless the class
// is moved to a different module in its own
personal file)
writeln(c.displayCounter);
}
```
The `counter` member variable isn't really protected from rogue
accesses (if these accesses are done by the code in the same
source file) and this behavior differs from C++.
Re: Is defining get/set methods for every field overkill?
On Monday, 21 November 2022 at 23:25:21 UTC, []() {}() wrote:
On Monday, 21 November 2022 at 11:56:59 UTC, Ali Çehreli wrote:
..
You took the question as whether to define them for class
hierarchies, safety-critical systems, etc.
Ali
Or even in a very, very simple counter class:
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;
}
}
But why give a C++ code example? 廊
Re: Is defining get/set methods for every field overkill?
On Monday, 21 November 2022 at 11:56:59 UTC, Ali Çehreli wrote:
..
You took the question as whether to define them for class
hierarchies, safety-critical systems, etc.
Ali
Or even in a very, very simple counter class:
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: "Little Scheme" and PL Design (Code Critique?)
On Thursday, 17 November 2022 at 22:05:45 UTC, jwatson-CO-edu wrote: * Compatibility with both Windows and Linux. What do I need to consider? - Can I create threads/processes under Windows? [core.thread][1] and [std.process][2] provide platform-independent interfaces for this that should work on both Windows and Linux. [1]: https://druntime.dpldocs.info/core.thread.html [2]: https://phobos.dpldocs.info/std.process.html
Re: Is defining get/set methods for every field overkill?
On Monday, 21 November 2022 at 11:34:50 UTC, thebluepandabear wrote: Best regards, Alexandru. Thanks but I haven't reached that yet. Well, I wish you'll reach as soon as possible :)
Re: Is defining get/set methods for every field overkill?
On 11/20/22 14:37, [] () {} () wrote:
> so, as I understand it, your're against the use of private, against the
> use of class, and against the use of encapsulation.
I never implied any of that.
> .. good luck with your career as a software engineer (but please, for
> all our sakes, don't work on any safety-related systems, and especially
> not the ones running in my car).
I haven't written any code that runs on the car yet but I did and still
do work in autonomous vehicle projects:
https://techcrunch.com/2017/04/04/daimler-and-bosch-fully-autonomous-cars-within-5-years/
(That partnership is no more at this time.)
And coincidentally, to reply to your post that included Autosar, MISRA,
etc. I am very well aware of those standards because I did contribute to
the team that wrote our coding standards by going through every single
one of their rules.
As one would expect, there was no argument on whether to use getters and
setters or direct public access for that project: We decided no public
access to members.
This discussion came to this point because you and I understood the
question differently: I took the OP's question literally: "Is defining
get/set methods for every field overkill?"
You took the question as whether to define them for class hierarchies,
safety-critical systems, etc.
Ali
Re: Is defining get/set methods for every field overkill?
Best regards, Alexandru. Thanks but I haven't reached that yet.
Re: Is defining get/set methods for every field overkill?
On 11/20/22 23:01, [] () {} () wrote:
> On that basis, I might be tempted to agree with you're point of view ->
> never, ever, ever, ever, use classes in D.
That's not my point of view.
Ali
Re: Is defining get/set methods for every field overkill?
On Monday, 21 November 2022 at 11:20:31 UTC, Alexandru Ermicioi
wrote:
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear
wrote:
[...]
Dunno if someone mentioned, but you can minimize use of
boilerplate by hiding it into mixin templates. Say you have:
```D
mixin template Property(T) {
private T subject_;
T Property() { return subject_; }
void Property(T value) { subject_ = value; }
}
```
The you can use it in your class to define properties of class:
```D
class MyMegaPropertyClass {
mixin Property!(string) myFancyProperty;
}
auto c = new MyMegaPropertyClass()
c.myFancyProperty = "indeed"
```
The only issue is that, by using eponymous naming you also
block any access of underlying subject_ or any other
miscellaneous info that you may add.
Best regards,
Alexandru.
You can use mixin templates to also define contlstructors, or any
other boilerplate that is buildable using meta programming
capabilities in D.
It would be awesome to have smth like Lombok from java but in D
using mixin templates.
Best regards,
Alexandru
Re: Is defining get/set methods for every field overkill?
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear
wrote:
I am creating a TUI library and I have a class with the
following constant fields:
```
class Label : Renderable {
const string text;
const TextAlignment textAlignment;
const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color)
{
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
I am debating whether or not I should add getter methods to
these properties. On one hand, it will inflate the codebase by
a lot, on the other hand -- in other languages like Java it is
a good practice:
```
class Label : Renderable {
private const string text;
private const TextAlignment textAlignment;
private const Color color;
this(Dimensions dimensions, string text, TextAlignment
textAlignment, Color color) {
this.dimensions = dimensions;
this(text, textAlignment, color);
}
this(string text, TextAlignment textAlignment, Color color)
{
this.text = text;
this.textAlignment = textAlignment;
this.color = color;
}
string getText() const {
return text;
}
TextAlignment getTextAlignment() const {
return textAlignment;
}
Color getColor() const {
return color;
}
override Cell[] render() const {
Cell[] cells;
for (int x = 0; x < 0 + text.length; ++x) {
cells ~= Cell(Coordinates(x, 0), text[x], color);
}
return cells;
}
}
```
It's not a lot of code that has been added but if you have a
class with say 10 different fields, adding getter methods would
definitely increase the code size by a lot, so what are you
guys thoughts on this?
Dunno if someone mentioned, but you can minimize use of
boilerplate by hiding it into mixin templates. Say you have:
```D
mixin template Property(T) {
private T subject_;
T Property() { return subject_; }
void Property(T value) { subject_ = value; }
}
```
The you can use it in your class to define properties of class:
```D
class MyMegaPropertyClass {
mixin Property!(string) myFancyProperty;
}
auto c = new MyMegaPropertyClass()
c.myFancyProperty = "indeed"
```
The only issue is that, by using eponymous naming you also block
any access of underlying subject_ or any other miscellaneous info
that you may add.
Best regards,
Alexandru.
