Partial class implementation

[Bill Baxter]

Reiner Pope wrote:
> 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?

I think that's ok, insofar as what you've written.  What you can't do is 
import more than one version of toString, even if they are unabmiguous 
w.r.t. the usual overloading rules:

----
module a;
struct A {  ... }
string toString(A) { ... }
----
module b;
struct B {  ... }
string toString(B) { ... }
----
import a;
import b;
void main()
{

}
----

That fails just importing the two modules, so I didn't bother actually 
trying to call the toString methods.

The above would work fine if you had the two flavors of 'toString' all 
consolidated in one module.  It would also work fine with 'static 
import' and explicit use of a.toString and b.toString.  But what doesn't 
work is resolving an overload to different modules based on the argument 
type.

Apparently it's a big hairy deal to implement and the bane of 
compiler-writers' existence.  But C++ allows it.  Walter believes it's 
not necessary, though.  And so far he seems right.  But it does mean you 
need to put some things inside classes (like toString) that could be 
free functions if protection levels were the only concern.

--bb