Le 14/12/2011 20:41, Adam Wilson a écrit :
Hello Everyone,
I want to start this conversation by pointing out that I come from a
C/C++/C# background and my ideas and frustrations in this post will be
colored by that history.
When I first approached D, the idea of an 'export' confused me. I've
since figured out, at least in libraries, that in C# terms D's 'export'
means 'public'. However, this raise a problem, specifically, how do I
export a protected member from a dynamic library?
Here is a table of D's scoping system mapped to C#'s scoping system as I
understand it:
D C#
export public
public internal
protected internal protected
private private
I believe this illustrates the problem clearly. There is no protected
scope that is available to the outside world. The ONLY way to export a
function in D is to mark is as an export. I have tested this against
2.056 and without the export identifier, the function never makes it
into the .lib file. But Protected functions are clearly intended to be
used outside of the library that they are built in. Currently, D says
no; but without protected functions, inheritance becomes very
troublesome. Any library of decent size is going to want to allow it's
consumers to inherit from it at some point. For example, just yesterday
I wrote four functions that overrode protected functions in .NET's WPF
library. Without access to these protected functions I would have been
simply unable to solve the problem. And my boss would have been VERY
unhappy about that.
I think the way export should work is more like an attribute or note to
the compiler that says "Hey Mr. Compiler, here is this public function,
compile it. And while you're at it, I set this little flag over here
that says you should export it as well." It would look something like
'export public' or 'export protected'.
So the new D->C# scope mapping table might look like this:
D C#
export public public
public internal
export protected protected
protected internal protected
private private
This would completely solve the issue of protected scoping in dynamic
libraries. As a note, 'export private' should be a compiler error.
I know there is a lot of resistance to making design changes to D2 at
this point, and rightly so. The biggest issue I see here is that it
breaks with TDPL. However, this is a major issue and one that will block
many people from picking up D for serious work. Support for inheritance
from dynamic libraries is a MUST HAVE for dynamic libraries to be truly
useful. As for maintaining backwards compatibility, a function with just
'export' could be easily mapped to 'export public' as that is it's
current behavior. Also, please note that I am not married to that
syntax. But a solution is required and I think that this one represents
a good compromise. It doesn't introduce any new keywords, fixes a major
design issue, and increases expressiveness and readability.
Any thoughts, objections, rants, raves? Walter, Andrei, thoughts?
The same goes for private virtual methods actually. They cannot be
called, but they can be reimplemented in subclasses.
If you put that detail asside, this is a neat idea. I'd love to see that
in D.
