On Thursday, 11 April 2013 at 04:23:07 UTC, xenon325 wrote:
On Wednesday, 10 April 2013 at 16:08:53 UTC, Andrei
Alexandrescu wrote:
It may as well be a mistake that nonvirtual functions are at
all part of a class' methods. This has been quite painfully
seen in C++ leading to surprising conclusions:
http://goo.gl/dqZrr.
"Non-Member Functions Improve Encapsulation" is invalid for D
because of implicit friends.
It was discussed before:
http://forum.dlang.org/post/[email protected]
--
Alexander
In some ways, implicit friends is the analogous to implicit
virtual. With implied virtual you can at least state "final" for
a reversal but with implied friends there's no way out other than
through band-aid measures which cause headaches.
Really, the generality of the problem is analogous to the reasons
why you do not allow implicit data typing or worse, implicit
declarations. So in D a fundamental rule is being violated. IMO,
everything should be explicit unless the intention can be
calculated to be 100% certain (i.e., no possible alternatives).
For example "auto" in D is fine, because the data typing is
certain, but a data type of a value in a JSON struct being
defined by the value is wrong, eg maybe the 0 (integer) was
supposed to be 0.0 (real).
BTW, the UFCS solution to non-virtual methods creates the old C++
problem of constantly re-typing in the same symbol name of the
class for every external member function. Not fun. Some syntactic
sugar may help, perhaps clever use of template's, I don't know.
--rt
