D versus Objective C Comparison

Don nospam at nospam.com
Tue Feb 3 00:13:38 PST 2009


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.



More information about the Digitalmars-d mailing list