Partial class implementation

[Reiner Pope]

Bill Baxter wrote:
> janderson wrote:
>> Robert Fraser wrote:
> 
>> There is no real point in arguing this.  My main argument is based on 
>> code refactorbility and design.  I find free functions are much more 
>> reuseable then member functions, look at algorithms in std (find, sort 
>> ect...).
> 
> Does that really hold true for D though?  Without Koenig lookup, free 
> functions don't have the same flexibility they do in C++.  You can write 
> generic template functions like find, sort, etc, where there is a single 
> implementation and callers have to implement the concept it requires. 
> But something like 'toString' as a non-member is pretty much impossible 
> in D.
> 
> --bb

I didn't realise there was an issue here, before; can you tell me if 
this is what you are talking about?

---

module a.b.c;

struct A {...}
string toString(A) {...}

---

module a.b;
import a.b.c;

class B
{
     A getInstanceOfA() {...}
}

---

module b;
import a.b;

void main()
{
     B b = new B();
     auto a = b.getInstanceOfA();
     string s = toString(a); // doesn't work
}

---

In this case, I can see it might be a surprise that it doesn't work, but 
is there anything worse than that? What's wrong with just importing 
a.b.c and carrying on? If you did any serious manipulations of 'a', then 
you would have to declare the type 'A' *sometime*; so you'd end up 
importing a.b.c anyway...

I'm just taking a guess at what you mean, though; if I'm completely off, 
can you please explain?


   -- Reiner