D vs. C#

[davidl]

在 Wed, 24 Oct 2007 08:54:16 +0800，Walter Bright  
<newshound1 at digitalmars.com> 写道:

> Vladimir Panteleev wrote:
>> With .NET, you can derive from a class in a compiled assembly without
>> having access to the source. You just add the assembly in the
>> project's dependencies and import the namespace with "using". In C,
>> you must use the included .h files (and .h files are a pain to
>> maintain anyway since you must maintain the declaration and
>> implementation separately, but that's not news to you).
>
> Yes, but that's a language bug, not anything inherent to native  
> compilers.
>
>> You must
>> still use .lib and .di files with D and such - although they can be
>> automated in the build process, it's still a hassle.
>
> D has the potential to do better, it's just that its a bit mired in the  
> old school.
>
>
>> Besides that, statically linking in the runtime seems to be a too
>> common practice, as "DLL hell" has been a discouragement for
>> dynamically-linked libraries in the past (side-by-side assemblies is
>> supposed to remedy that though). I guess the fault is not in the DLLs
>> themselves, it's how people and Microsoft used them...
>
> The solution to this is to have automatically generated versions for  
> each build of a DLL/shared library. I imagine that .net does the same  
> thing for assemblies.
>

The solution is banning those guys from creating changing DLL/shared  
libraries. They just have no idea of what DLLs are and how DLLs should be.  
Generating versions is a bad idea. Consider FireFox with its tons of  
plugins. Almost all plugins I use actually works well with *any* FireFox  
version. Just it bothers me to change the version no in the jar file.

Cause FireFox APIs & Javascript is something fixed. So the interface of  
what plugins rely on is fixed. That's basically how and what DLLs should  
be. Interface interacts with design. I can't imagine a good design yields  
changing interface.



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/