Walter: extend existing classes with new methods?

[Marcio]

    If I understood your argument correctly, you are saying that you 
can't have a compiler compile code for a class if the source is split 
across multiple source files? Because, after all, that's all we're 
talking about here. Class foo has some code in foo.d, some code in bar.d 
(it added methods to foo) and so on.

   Well, if we are going to use that argument, we might as well move 
back in time to the old days of Turbo Pascal 3.0. If you wanted to use a 
procedure Foo, it had to have already appeared in the source. So, for 
cases like recursive descendent parsers or recursive tree traversal you 
had to declare the function, and later have it appear again, with the 
body itself. This allowed you to have mutually recursive procedures. 
This was because the compiler couldn't do any look-ahead or 2-pass. Way 
to go, put the burden on the developer because of a compiler limitation. 
Fina when you have 64KB of RAM like the MSX I guess...

   I think compilers should serve developers, not the other way around.

   By the way, the reason Java source has so many "instanceof" is 
because it doesn't allow this type of extension. If the language allows 
extensions, you can easily code things with polymorphism by adding say 
isFoo to Object (return false) and overriding it in your Foo class 
(return true). No need for instanceof. You want to know if the object 
isFoo? Damn, just ask it. Use OO. This is a very common pattern of 
coding in systems like Smalltalk.

   I honestly believe that people who never used this feature in a 
language can't really grasp what they are missing. That's too bad. Just 
look at http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt  when he 
talks about frameworks, the need to extend base classes. To me that's a 
clear example of a problem that can be solved by this mechanism.

marcio


Kirk McDonald wrote:
>> No, I am asking for extending at compile-time. Example: You provide me 
>> with a library written in D, with full source, and my app can add 
>> methods to some of your classes. Then I compile the full source.
>>
>> This is quite doable, even in D.
>>
>> Adding methods at runtime is an issue if you allow plugins to be 
>> loaded from DLLs. If these plugins can add not only classes but also 
>> add methods to existing classes, then you need the functionality at 
>> runtime.
>>
>> I am being modest in my request. Compile-time extension would be 
>> straightforward and very useful.
>>
>> marcio
> 
> There is a problem with this.
> 
> class Foo { }
> 
> static if (is(typeof(Foo.bar))) {
>     const bool has_bar = true;
> } else {
>     const bool has_bar = false;
> }
> 
> /+ Add a 'bar' member to Foo somehow +/
> 
> Does Foo have a 'bar' member or not? In order for has_bar to be true, 
> the compiler would need to arbitrarily look ahead and see if class Foo 
> is changed later. This may well be impossible.
> 
> If instead you want has_bar to evaluate to false (because the 'bar' 
> member hasn't been added at the time the static if is evaluated), then 
> this leads to any number of problems. The class is suddenly different at 
> different points in the code. In a statically-typed language, this is 
> wrong, wrong, wrong.
>