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.