Walter: extend existing classes with new methods?

[Don Clugston]

Marcio wrote:
>> In C++ I used my "fastdelegate" template (on CodeProject) to hack 
>> delegates into C++. This lets you do something vaguely like:
>>
> [...]
>> Then, you can write
>>
>> void myfunc(StringWithURL s) {}
>>
>> and it will accept anything derived from String. 
> 
> 
>    I want existing String objects, belonging to class String, to be able 
> to understand asURL. Not a new class. Unless I misunderstood your 
> explanation. My understanding is that "derived from String" does not 
> include String.

Sorry, my wording was poor. Anything implicitly convertible to String 
will be implicitly convertible to StringWithURL. This obviously includes 
String itself.

>> It's unnecessarily inefficient, though -- not as lightweight as it 
>> should be.
>> Also things like delete don't work (they don't delete the base class).
> 
> 
>   If you could just add methods to the class, these methods would behave 
> the same as the ones defined in the class itself. No speed penalty.

Yes. That was a limitation of C++ templates, I think you could do better 
in D with the same idea. With my technique it would not be possible to 
add data members, though.

>   The feature request is quite simple actually. Allow a class C to be 
> defined not just in 1 file, but in N files. From many fragments. A class 
> is never a closed module in this case.

Simple to request, complicated to implement I would guess. Something 
defined in a DLL surely has to be a closed module?

>>>     Another scenario I would be interested to see working is how I 
>>> can have Object return false to "isWidget" but a Widget class return 
>>> true.
>>
>> Yeah, that's very common. Some cases can be done very easily:
>>
>> template (X)
>> void myfunc(X x) {
>> static if ( is( x.isWidget ) ) {
>>     ...
>> }
>> }
>>
>> but if you don't know the type at compile time, you're stuck.
>    Yeah, I'd rather just rely on polymorphism. Which can be done if the 
> source of a class can be split across multiple files. These extra 
> methods become regular methods, not second class.
> 
>> It's very imperfect, but might generate ideas.
> 
> 
>    Indeed. But in my mind, a compiler can do lots of interesting things 
> after compiling the full program. These extension methods would not be 
> hard. There are also all sorts of polymorphism optimizations that can be 
> done. SmartEiffel (used to be SmallEiffel) does all sorts of virtual 
> call optimizations because it can do a global analysis of thr code 
> (something Java can't do, for example, because of thr dynamic class 
> loading etc). Sometimes their compiler eliminates 98% of virtual calls. 
> It generates amazingly fast code.

I believe D is designed to allow those optimisations.

>   Anyway, just to say that if you are compiling a program to generate an 
> EXE, with no fancy dynamic loading etc, it should be possible to do 
> these global analysis and therefore also allow methods to be added from 
> different places. Like extending a framework by adding methods to base 
> classes so that all subclasses now receive the extra behavior. And that 
> includes Object itself.

I'd rather do that stuff with templates. If mixins were a little more 
powerful, you could use them to add the extra functionality to base 
classes. If you look at the example in the gaming article, it's clear 
that the designer of the framework *knows* where the extra functionality 
is going to be required. The problem is that the language doesn't give a 
nice way of expressing it.