On Monday, 6 October 2014 at 10:10:04 UTC, eles wrote:
On Saturday, 4 October 2014 at 15:29:57 UTC, John Colvin wrote:
On Saturday, 4 October 2014 at 11:19:52 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 04 Oct 2014 11:01:28 +0000
John Colvin via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com>
wrote:
On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via
Digitalmars-d-learn wrote:
> On Sat, 04 Oct 2014 10:27:16 +0000
> John Colvin via Digitalmars-d-learn
> <digitalmars-d-learn@puremagic.com>
> wrote:
I don't really see the point though.
class A
{
void foo(int a) { Afoo(this, a); }
}
then declare and define Afoo however you like.
That's hackish, bad and convoluted.
I disagree. It's simple and easy to understand.
And it does not/should not allow one to mess with the private
fields of the class, especially if Afoo is defined in another
module.
s/especially/only
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.
And on that matter, a function that is to be provided by
another module should be explicitly marked as such in its
declaration.
Otherwise, I could declare a function, forget to provide its
definition, still having the surprise that the code compiles
and runs with very strange results because some other module
provides a function that just happens to work.
I don't quite follow. Example?
Let's not even say how messy this could get with version()
where you could disable a function definition by error, in one
version, but still have a software that compiles and runs
nowhere.
