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?
--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
