On Monday, 6 October 2014 at 12:36:41 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 06 Oct 2014 11:54:55 +0000
John Colvin via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com>
wrote:
I disagree. It's simple and easy to understand.
and hackish.
D is very amenable to slightly hackish code.
This is the only genuine problem I can see that requires a
language extension. Separating class definition from method
definition in to different compilation units doesn't allow
access to private members without very nasty hacks.
no hacks needed.
I meant that without a language change, one does need hacks.
== pkg.classdef.d ==
module pkg.classdef;
class A {
private:
int hiddenField;
int bar ();
}
== pkg.othermodule.d ===
module pkg.othermodule;
import pkg.classdef;
// this imlements A.bar() declared in pkg.classdef:
@implementation(A) int bar () { return this.hiddenField; }
compiler is perfectly able to put A.bar() implementation in the
scope
of A, and then A.bar can access anything in A. it's the same as
declaring bar() in class definition.
That would be nice, although personally I'd prefer
int A.bar() { return this.hiddenField; }
as it's less verbose and would be familiar to c++ programmers.
