On Saturday, 19 November 2022 at 23:05:30 UTC, thebluepandabear
wrote:
..
btw. Although this thread has well and truly exhausted it
usefulness, the question you posed primarly relates to
encapsulation, and as such, I think Scott Myers provided a
reasonable answer to your question - more
On Saturday, 19 November 2022 at 22:57:36 UTC, [] () {} () wrote:
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear
wrote:
...
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 --
On Thursday, 17 November 2022 at 04:39:35 UTC, thebluepandabear
wrote:
...
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:
You really
On Saturday, 19 November 2022 at 19:54:59 UTC, Ali Çehreli wrote:
On 11/19/22 01:05, [] () {} () wrote:
> All this because some programmer wanted to save a few key
strokes, or
> did not anticipate change, or did not anticipate the need to
ensure data
> is valid before assigning it, or returning
On Saturday, 19 November 2022 at 19:59:20 UTC, Ali Çehreli wrote:
..
...
Ali
The 10 years was mentioned, because it was what I learnt over
that period (well, long before that actually). It wasn't
mentioned to demonstrate that I have some superior knowledge.
Object data needs to be
On Saturday, 19 November 2022 at 19:59:20 UTC, Ali Çehreli wrote:
On 11/19/22 01:43, [] () {} () wrote:
> do it your way for the next 10 years, and
> I bet you will eventually come to a different point of view
;-)
Hm... I am responding without reading the rest of the thread so
I don't know
On Saturday, 19 November 2022 at 04:27:14 UTC, []() {}() wrote:
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,
On 11/19/22 01:43, [] () {} () wrote:
> do it your way for the next 10 years, and
> I bet you will eventually come to a different point of view ;-)
Hm... I am responding without reading the rest of the thread so I don't
know whether you've mentioned the 10 years more but here it goes: I hope
On 11/19/22 01:05, [] () {} () wrote:
> All this because some programmer wanted to save a few key strokes, or
> did not anticipate change, or did not anticipate the need to ensure data
> is valid before assigning it, or returning it.
>
> So no. It's not overkill. It's called software
On 11/18/22 20:13, [] () {} () wrote:
> 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 ;-)
It depends. Majority of my structs are pure data. When there is no
invariant to protect, then there is no reason
On 11/18/22 19:35, [] () {} () wrote:
> 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.
UFCS was mentioned before in the same context but I think what is meant
was
On Thursday, 17 November 2022 at 22:05:45 UTC, jwatson-CO-edu
wrote:
[`Atom`](https://github.com/jwatson-CO-edu/SPARROW/blob/main/lil_schemer.d#L66)
(unit of data), I throw it on the heap and never bother to delete it. I
understand that D does GC for me. I am interested in using either [timed
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
On Saturday, 19 November 2022 at 14:52:23 UTC, ag0aep6g wrote:
That's essentially just a function that returns its pointer
parameter. So the program boils down to this:
```D
@safe:
int* fp(return scope int* p) { return p; }
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
OK, so how do I make `lf` implicitly scope?
By explicit/implicit I just meant this:
scope explicit = new int;
int x;
auto implicit =
That's probably not helping with whatever you want to accomplish.
On Saturday, 19 November 2022 at 14:52:23 UTC, ag0aep6g wrote:
That's essentially just a function that returns its pointer
parameter. So the program boils down to this:
@safe:
int* fp(return scope int* p) { return p; }
void main()
{
int* p;
{
auto lf = new int;
p =
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
wrote:
Hi,
The following seems like a bug to me (reduced code, FILE*
changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf =
On 19.11.22 15:07, Nick Treleaven wrote:
Hi,
The following seems like a bug to me (reduced code, FILE* changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new int);
Hi,
The following seems like a bug to me (reduced code, FILE* changed
to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new int);
p = lf.fp;
}
assert(p != null); //
On Saturday, 19 November 2022 at 10:17:19 UTC, []() {}() wrote:
On Saturday, 19 November 2022 at 09:51:09 UTC, []() {}() wrote:
...
no. in C# it breaks ABI. that is why its not acceptable in my
team.
of course that's not the reason we don't use public member
variables in classes.
the
On Saturday, 19 November 2022 at 09:49:18 UTC, thebluepandabear
wrote:
I am too dumb to know what ABI is
https://en.wikipedia.org/wiki/Application_binary_interface
On Saturday, 19 November 2022 at 09:49:18 UTC, thebluepandabear
wrote:
On Saturday, 19 November 2022 at 09:26:49 UTC, Andrey Zherikov
wrote:
On Saturday, 19 November 2022 at 09:12:26 UTC,
thebluepandabear wrote:
That's the point many people have given here which is not
convincing him, even
On Saturday, 19 November 2022 at 09:26:49 UTC, Andrey Zherikov
wrote:
On Saturday, 19 November 2022 at 09:12:26 UTC, thebluepandabear
wrote:
That's the point many people have given here which is not
convincing him, even though it is quite great.
I think we all know the answer here
IMHO
On Saturday, 19 November 2022 at 03:52:41 UTC, thebluepandabear
wrote:
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 {
On Saturday, 19 November 2022 at 09:51:09 UTC, []() {}() wrote:
...
no. in C# it breaks ABI. that is why its not acceptable in my
team.
of course that's not the reason we don't use public member
variables in classes.
the reason we don't use them, is because (1) we always anticpiate
On Saturday, 19 November 2022 at 09:51:09 UTC, []() {}() wrote:
no. in C# it breaks ABI. that is why its not acceptable in my
team.
Every company works differently. Yours are using .net and (I
guess) ships dlls so you must care about ABI with existing
software. In my company we use static
On Saturday, 19 November 2022 at 09:26:49 UTC, Andrey Zherikov
wrote:
On Saturday, 19 November 2022 at 09:12:26 UTC, thebluepandabear
wrote:
That's the point many people have given here which is not
convincing him, even though it is quite great.
I think we all know the answer here
IMHO
On Saturday, 19 November 2022 at 09:26:49 UTC, Andrey Zherikov
wrote:
On Saturday, 19 November 2022 at 09:12:26 UTC, thebluepandabear
wrote:
That's the point many people have given here which is not
convincing him, even though it is quite great.
I think we all know the answer here
IMHO
On Saturday, 19 November 2022 at 09:12:26 UTC, thebluepandabear
wrote:
That's the point many people have given here which is not
convincing him, even though it is quite great.
I think we all know the answer here
IMHO you are both right :)
You are speaking about API compatibility, `[]()
On Saturday, 19 November 2022 at 09:12:26 UTC, thebluepandabear
wrote:
That's the point many people have given here which is not
convincing him, even though it is quite great.
I think we all know the answer here
IMHO you are both right :)
You are speaking about API compatibility, `[]()
On Saturday, 19 November 2022 at 09:05:42 UTC, []() {}() wrote:
Once you refactor your class (creating actual private member
variables and creating getter/setter methods, you are almost
certainly going to break binary compatability, and when you
send your update compiler library to your
That's the point many people have given here which is not
convincing him, even though it is quite great.
I think we all know the answer here
On Saturday, 19 November 2022 at 04:47:57 UTC, thebluepandabear
wrote:
..
Of course in C# this argument wouldn't exist because you could
just do `{ get; set; }`, and I really wish D had something
similar
If D had C#'s 'automatic' property syntax, it would as
meaningless in D as it is in
On Saturday, 19 November 2022 at 04:13:33 UTC, []() {}() 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
33 matches
Mail list logo
