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. 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.

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.

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.

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.

On Monday, 6 October 2014 at 11:54:56 UTC, John Colvin wrote:
> 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 quite follow. Example?

Well, in the OP example, imagine that I was trying to compile this module along with another one that simply happened to have a method defined in a way that the linker would have find it.

I would have compiled with:

dmd app.d app2.d

and be unaware what bug I have introduced because I forgot do declare formula() as abstract in the first class.

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.

> 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.

== 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.

On Monday, 6 October 2014 at 12:16:14 UTC, eles wrote:
> On Monday, 6 October 2014 at 11:54:56 UTC, John Colvin wrote:
>> 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 quite follow. Example?
>
> Well, in the OP example, imagine that I was trying to compile this module along with another one that simply happened to have a method defined in a way that the linker would have find it.
>
> I would have compiled with:
>
> dmd app.d app2.d
>
> and be unaware what bug I have introduced because I forgot do declare formula() as abstract in the first class.

This isn't a problem. You're not going to get the name-mangling right by accident. Even for free functions the module name is mangled in.

The only way this can happen is with extern(C) functions, which is because C doesn't mangle it's function names.

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.

On Mon, 06 Oct 2014 15:44:34 +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.
D allows to write hackish code, and it's good. but if we can provide a way to write less hackish code, it's good and preferable, i think. ;-)

> > no hacks needed.
> I meant that without a language change, one does need hacks.
i see.

> 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.
i was trying to not change grammar, that's why i invented that horribly-looking @implementation attribute. this way the code is still marked as a hack, but "officially endorsed" hack. besides, attribute allows to use code blocks:

  @implementation(A) {
    int foo () { ... }
    void bar () { ... }
  }

or even:

  @implementation(A):
    int foo () { ... }
    void bar () { ... }

sure, it has it's own pack of problems:

  @implementation(A) {
    @implementation(B) {
      // I'M LOST!
    }
  }

but we can have both! ;-)

On Monday, 6 October 2014 at 13:23:55 UTC, John Colvin wrote:
> On Monday, 6 October 2014 at 12:16:14 UTC, eles wrote:
>> On Monday, 6 October 2014 at 11:54:56 UTC, John Colvin wrote:
>>> 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

> This isn't a problem. You're not going to get the name-mangling right by accident. Even for free functions the module name is mangled in.

It is. I could erase the definition of an identical class in another .d file and accidentally leave an orphan definition method therein.

> The only way this can happen is with extern(C) functions, which is because C doesn't mangle it's function names.

This too is a hole. Why to leave holes?

I like the "fromage à trous":

http://fr.wikipedia.org/wiki/Paradoxe_du_fromage_à_trous

But not in my software.

On Monday, 6 October 2014 at 15:44:36 UTC, John Colvin wrote:
> 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.

So, you admit it is a hack! Gotcha!

On Monday, 6 October 2014 at 16:02:40 UTC, eles wrote:
> On Monday, 6 October 2014 at 13:23:55 UTC, John Colvin wrote:
>> On Monday, 6 October 2014 at 12:16:14 UTC, eles wrote:
>>> On Monday, 6 October 2014 at 11:54:56 UTC, John Colvin wrote:
>>>> 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
>
>> This isn't a problem. You're not going to get the name-mangling right by accident. Even for free functions the module name is mangled in.
>
> It is. I could erase the definition of an identical class in another .d file and accidentally leave an orphan definition method therein.

Unless I misunderstand you, this can't happen. Class methods are mangled to contain the module name and the class name. I can't think of a way of getting the same mangling and getting a bad substitution without either

a) pragma(mangle, ...)

or

b) you have 2 modules with the same name, containing classes with the same name, which you compile completely separately (to prevent the compiler complaining about the duplication), then link the results together. This would also work for free functions.

a) is a deliberate feature. b) has bypassed the compiler completely, there's no way it can know.

You're never going to do it by accident.

>> The only way this can happen is with extern(C) functions, which is because C doesn't mangle it's function names.
>
> This too is a hole. Why to leave holes?

Because it's how C linkage works and if we're using extern(C), it means we want C linkage. That's the point of extern(C).