class extensions

[janderson]

Alexander Panek wrote:
> Alexander Panek wrote:
>> Lars Ivar Igesund wrote:
>>> [...]
>>> It will also be directly detrimental to maintainability when used for 
>>> user
>>> defined types, as you no longer will be able to decide where a 
>>> function is
>>> implemented by only looking at the call site (given inheritance and
>>> polymorphism this can in cases be difficult enough, but at least you 
>>> have a
>>> type hierarchy to look to).
>>
>> Well, usually a simple change to the import list will reveal where 
>> each functions are defined. I wouldn't see that as an argument against 
>> this feature.
>>
>> Apart from that, in an ideal world, the code is well documented enough 
>> to not have to determine the location of a function/method 
>> implementation yourself, anyways. Of course, this is the *ideal*, but 
>> maybe this encourages some to document better.
> 
> On the other hand, the ambiguity problem:
> 
> class A {
>     int foo (int);
> }
> 
> int foo (A, int);
> 
> ..leads or at least may lead to maintenance problems, anyways.
> 
> (Yes, I might have missed the point in the other post :P)

Perhaps, but even without interchangeability warning signs go up for me 
if you have a method and a function that have the same signature.