On Wednesday, 25 July 2018 at 18:37:55 UTC, Manu wrote:
On Wed, 25 Jul 2018 at 10:45, Atila Neves via Digitalmars-d
<[email protected]> wrote:
On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
But my point is, that exact reasoning extends to the
hypothetical ref
argument as the return value.
If a property function sees fit to return by-value (ie, struct
is
small), then a function receiving that object will also receive
the
argument by-value.
That's a good point. I mean, with code not under one's control it
could happen otherwise, but most likely not.
This will be the usual pattern. When a type becomes large
enough to
want to pass it by ref, any property that returns one will also
most
likely return by ref.
Yep.
For context, I
think that getters are a faint code smell and that setters
always
stink.
So, you're reducing the power of the properties argument in
principle?
Yes, as long as it's code I write or review.
> S s;
> s.member.mutate();
It'd take roughly 5s between me seeing this in code review and
typing the words "Law of Demeter violation". To me that's
TRWTF.
I don't understand what you're saying here?
I think this case is equally hard to spot as the
passing-property-as-ref-arg case.
That unless it's a UFCS chain there shouldn't be more than one
dot. One should attempt to not call functions on returned
members. It should be `s.mutate()` where `member` is aliased this
or has `mutate` manually forwarded.
That is: don't "reach in" to objects, it's bad design anyway and
the bug doesn't exist if you don't.
