Re: Is defining get/set methods for every field overkill?
On Thursday, 24 November 2022 at 05:41:11 UTC, Mike Parker wrote:
On Thursday, 24 November 2022 at 03:49:16 UTC, []() {}() wrote:
I broke a forum rule by critically analysing your blog?
Wow.
Criticize my blog posts all you want. Just stop please stop
derailing threads. I'm going to delete further off topic posts
in this thread.
isnt the thread about encapsulation and classes??
isnt your blog about the same??
Re: Is defining get/set methods for every field overkill?
On Thursday, 24 November 2022 at 03:49:16 UTC, []() {}() wrote:
I broke a forum rule by critically analysing your blog?
Wow.
Criticize my blog posts all you want. Just stop please stop
derailing threads. I'm going to delete further off topic posts in
this thread.
Re: Is defining get/set methods for every field overkill?
've modified the code since then so that `private` isn't used, etc. Also thanks for that code improvement that you did, quite nice.
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 13:52:18 UTC, ryuukk_ wrote:
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;
As for the get/set, i almost never use `private`, and i never
use getter/setter to just access variables, it's pointless imo
Unless you expect your users to extend/override your types,
then it make sense, but i personally prefer composition, as i'm
not a fan of OOP
Thanks for the input, I've modified the code since then so that
`private` isn't used, etc.
Re: Is defining get/set methods for every field overkill?
I broke a forum rule by critically analysing your blog? Wow. Erm... You went off topic.
Re: Is defining get/set methods for every field overkill?
On Thursday, 24 November 2022 at 02:00:15 UTC, Mike Parker wrote: On Wednesday, 23 November 2022 at 23:35:59 UTC, thebluepandabear wrote: Please stop, we get it... I'm not a moderator so I cannot enforce rules but there is NO need to continue this debate here. This software 'religiousness' is too much. I am a moderator and I can enforce the rules. So yes, let's please drop this tired old debate about private and get back on topic. Or just let the thread die. Thanks. I broke a forum rule by critically analysing your blog? Wow.
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 23:35:59 UTC, thebluepandabear wrote: Please stop, we get it... I'm not a moderator so I cannot enforce rules but there is NO need to continue this debate here. This software 'religiousness' is too much. I am a moderator and I can enforce the rules. So yes, let's please drop this tired old debate about private and get back on topic. Or just let the thread die. Thanks.
Re: Is defining get/set methods for every field overkill?
That the D module dissolves that perimeters of my types - in relation to other code in the same module, is a really odd design decision that I cannot, as yet, get my head around. That is, I can see no possible way in which this design decision can enhance my coding, even after having given if way more thought than it deserves. Please stop, we get it... I'm not a moderator so I cannot enforce rules but there is NO need to continue this debate here. This software 'religiousness' is too much.
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 13:24:37 UTC, Tejas wrote: Please let's not repeat previous topics `private` will be enforced at module scope, for better or for worse, there has already been a [1000 post thread](https://forum.dlang.org/post/lqlllioynzfmpaozw...@forum.dlang.org) that resulted in basically nothing except someone creating a `private this` pull for curiosity that will never be accepted in the language Look at the very last post where the moderator had to externally kill the thread to prevent it from being revived/argued further It's the same guy. He knows what he's doing and will not let this go, like a vengeful spirit.
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 22:43:54 UTC, []() {}() wrote:
My last post ;-)
It seems far too many people conflate classes and oop.
You can do oop without classes (whether you would want to is
another question all together).
You can also use class-types without doing oop.
A class-type is just a type. If you're against a class-type, you
must also be against an int type, a char type, a function type,
and enum type.
Now *clearly* many D users appear to be in the anti oop camp.
But please don't be in the anti class-type camp.
Class 'types' really are an extremely useful and important tool
in software engineering, regardless of whether you use them as a
tool to do oop, or not.
That the D module dissolves that perimeters of my types - in
relation to other code in the same module, is a really odd design
decision that I cannot, as yet, get my head around. That is, I
can see no possible way in which this design decision can enhance
my coding, even after having given if way more thought than it
deserves.
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 13:24:37 UTC, Tejas wrote:
On Wednesday, 23 November 2022 at 11:06:12 UTC, []() {}() wrote:
On Wednesday, 23 November 2022 at 09:51:46 UTC,
FeepingCreature wrote:
Why then should a programming language insist that all other
code in the module should be able to bypass my specification,
and do as it pleases to my type?
Please let's not repeat previous topics
`private` will be enforced at module scope, for better or for
worse, there has already been a [1000 post
thread](https://forum.dlang.org/post/lqlllioynzfmpaozw...@forum.dlang.org) that resulted in basically nothing except someone creating a `private this` pull for curiosity that will never be accepted in the language
Look at the very last post where the moderator had to
externally kill the thread to prevent it from being
revived/argued further
I wasnt discussing private, and it's rather off the point
somewhat.
I was responding to the claims that were made in the blog that
someone mentioned in this thread:
https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
The claim was, that Friends in C++ breaks encapsulation. But that
is not correct. It merely expands the perimeter of that
encapsulation by putting a door in the wall, along with a guard
at the door. The encapsulation remains. The encapsulation itself
is not enough however, hence the guard at the door.
And if you program classes 'as types' (whether you additionally
do OOP or not - as that too is off the point), then coming to D
and finding out that in the context of a module, your class is
not even a type (because it simply has no perimeter at all in a
module), then I cannot see how that enhances encapsulation, as
was claimed in the blog. How can that possibly enhance
encapsulation? That makes no sense.
If the blog were published in a journal.. well.. it would never
get published in a journal ;-)
Critical analysis remains a great tool, even in relation to
'blogs'.
Re: Can we ease WASM in D ?
On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics
wrote:
Dear community,
I look some day ago to the D wasm page:
-> https://wiki.dlang.org/Generating_WebAssembly_with_LDC
And since then I ask myself can we at compile time convert a D
code to an extern C code for wasm ?
Indeed, if a library/framework would wrap this to let end user
write his code in plain D that would be awesome.
So did you think it is possible to do it by using
metaprogramming, mixin, mixin template, mixin string … ?
Thanks for your ideas
It should not be too hard to do that using mixin templates. The
concept is the same from my `@ExportD` that I'm using on my
engine.
What `@ExportD` does is to create a new function based on the
function target function [or even classes] which all it does is
call that (or even attach a GC.root as needed ), and generates
factory functions for classes or create some `extern(C) export`
the function.
I have done the same thing also for Lua and Java, don't seem that
hard to do it with WASM. The only difference is that you will
need to mixin template yourself (I do it at the end of file),
then I iterate through the module members containing your `@wasm`
UDAs, and generate the functions needed.
Remember that you could also use things such as
`@wasm("myNewFunctionName")` and handle such cases.
But for me, working with D without a D runtime is simply not
worth. That being said, if we had a working D runtime for WASM I
would be adapting my engine to support it too.
Re: Can we ease WASM in D ?
On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics wrote: Dear community, I look some day ago to the D wasm page: -> https://wiki.dlang.org/Generating_WebAssembly_with_LDC And since then I ask myself can we at compile time convert a D code to an extern C code for wasm ? Thanks for your ideas Not exactly related, but this effort seemed to have gotten pretty far. But is old now https://code.dlang.org/packages/spasm
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?
Little optimization, you could prefill your cells instead of
creating a new dynamic array every frames not good for the gc
```D
class Label : Renderable {
private const string text;
private const TextAlignment textAlignment;
private const Color color;
private const Cell[] cells;
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.cells.length = test.length;
this.textAlignment = textAlignment;
this.color = color;
// fill cells here
for (int x = 0; x < text.length; x++)
this.cells[x] = Cell(Coordinates(x, 0), text[x],
color);
}
string getText() const {
return text;
}
TextAlignment getTextAlignment() const {
return textAlignment;
}
Color getColor() const {
return color;
}
override Cell[] render() const {
return cells;
}
}
```
As for the get/set, i almost never use `private`, and i never use
getter/setter to just access variables, it's pointless imo
Unless you expect your users to extend/override your types, then
it make sense, but i personally prefer composition, as i'm not a
fan of OOP
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 11:06:12 UTC, []() {}() wrote:
On Wednesday, 23 November 2022 at 09:51:46 UTC, FeepingCreature
wrote:
Why then should a programming language insist that all other
code in the module should be able to bypass my specification,
and do as it pleases to my type?
Please let's not repeat previous topics
`private` will be enforced at module scope, for better or for
worse, there has already been a [1000 post
thread](https://forum.dlang.org/post/lqlllioynzfmpaozw...@forum.dlang.org) that resulted in basically nothing except someone creating a `private this` pull for curiosity that will never be accepted in the language
Look at the very last post where the moderator had to externally
kill the thread to prevent it from being revived/argued further
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 09:51:46 UTC, FeepingCreature wrote: The module is the capsule. D is simply not interested in building a capsule around a class. D does not let "anyone" pass through, it lets "anyone in the module" pass through, because the module is the wall. I think this is a stronger concept of encapsulation than C++ friends because the encapsulation is lexical rather than just declarative. But if I write a class specification, then that class will be its own capsule. It will be its own type, just like a built in type. It will have its own interface by which other code can interact with it, just like a built in type. Why then should a programming language insist that all other code in the module should be able to bypass my specification, and do as it pleases to my type? If this applied to built in types, imagine the chaos that could follow from that. Well, the class is a type as well. I struggle to see how treating other code in the module as though it is a part of the specification of my type (ie. all that code is essentially inside the perimeter of my class type), benefits me as software engineer. I am surely missing something here. In C++, if I want another type to interact with my type, in a tightly coupled manner, then I can explicately authorise that interaction very easily, using friend. Now when I see my code, or others read my code, they know intent. In a D module, intent cannot be discovered so easily, since it cannot be explicately declared. Not even the compiler knows your intent. It can only assume everything you typed in the module is correct. And now your counter class overflows...and boom!
Re: Is defining get/set methods for every field overkill?
On Tuesday, 22 November 2022 at 21:45:29 UTC, []() {}() wrote:
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.
The module is the capsule. D is simply not interested in building
a capsule around a class. D does not let "anyone" pass through,
it lets "anyone in the module" pass through, because the module
is the wall. I think this is a stronger concept of encapsulation
than C++ friends because the encapsulation is lexical rather than
just declarative.
Proper way to override (swap) runtime and phobos. [feature request?]
for development purposes. is there are correct way to somehow (partially or complete) override druntime and phobos? or, maybe, some code injection/patching mechanisms during compilation of own code.
