D versus Objective C Comparison

[Don]

Nick Sabalausky wrote:
> "Michel Fortin" <michel.fortin at michelf.com> wrote in message 
> news:gm8dhq$sj7$1 at digitalmars.com...
>> On 2009-02-02 21:19:52 -0500, Daniel Keep <daniel.keep.lists at gmail.com> 
>> said:
>>
>>>
>>> Michel Fortin wrote:
>>>> [stuff]
>>> Wouldn't this be just as well served with Walter's "universal function
>>> syntax"; ie:
>>>
>>> void backup(File this, string backupPath)
>>> {
>>>   copy(this.path, backupPath ~ "/" ~ this.name);
>>> }
>>>
>>> File someFile;
>>> someFile.backup(backupPath);
>> It would work in your example, but not in mine. Note the difference:
>>
>> foreach(child; children)
>> child.backup(backupPath ~ "/" ~ this.name);
>>
>> Statically, child is a Node here. If at runtime child is a File, the 
>> backup function is overriden by the FileBackup extension of File, so it'd 
>> call the backup function from FileBackup, not NodeBackup. If at runtime 
>> child is a Directory, it'll call DirectoryBackup's backup function. At 
>> least, that's what it would do in Objective-C using categories. And that's 
>> why you don't need the visitor pattern in Objective-C.
>>
>> -- 
>> Michel Fortin
>> michel.fortin at michelf.com
>> http://michelf.com/
>>
> 
> I had been slowly coming around to the idea of having that universal 
> function syntax instead of C#-style explicit extension methods, but maybe 
> this need for dynamic dispatch is a good reason to prefer explicit extension 
> methods:
[snip]

I think that allowing interfaces to be declared AFTER the objects which 
satify them, would be a more general solution.
Create a vtable, fill it with all the entries from the object's vtable, 
and add any extra functions you want.
Then you could allow structs to support interfaces, for example.